I have a couple of repos I want to publish on npm. But these are browser repos, thus pose a problem: the main property in package.json appears to be for specifying a node (not browser) module.
From https://docs.npmjs.com/files/package.json#main
main
The main field is a module ID that is the primary entry point to your program. That is, if your package is named foo, and a user installs it, and then does require("foo"), then your main module's exports object will be returned.
This should be a module ID relative to the root of your package folder.
For most modules, it makes the most sense to have a main script and often not much else.
So what should I use for a npm package for browser repos? Just omit the field? Point to the repo bundle? Something else?
I checked out several more browser repos and it appears that this is the current convention (Taken from the Three.js & Rollup github repos):
"main": "build/three.js",
"jsnext:main": "build/three.module.js",
"module": "build/three.module.js"
main points to the <script> code while jsnext:main and module point to the es6 module.
There are a few naming conventions for the module bundle:
foo.module.js
foo.es.js
foo.mjs
and so on.
https://github.com/rollup/rollup/wiki/pkg.module, referred above, appears to be a reasonable reference. Google this for more:
main jsnext:main module properties package.json
Bottom line: there are conventions but no standards.
Related
I work on a component library and a React app that makes use of that component library. My component library looks like this when I build it:
/core
/components
/MyComponent
/utils
/hooks
This means when we import a component, it looks like this:
import '#our-package/core/components/MyComponent/MyComponent';
Is there a way we can make the components folder our entry point? The utils and hooks folders should not be accessible. Ideally, we could use:
import `#our-package/core/MyComponent/MyComponent`
I'm reading about the node main property you can use in package.json but it doesn't look like it works with folders. Is there another way to do this?
You could move your folder upwards, in the same directory as your package.json.
If you're targeting a newer version of Node.js, you can also make use of the new packages structure. You can basically say exactly where #our-package/core/subpath points at in your #our-package/core package. It has a whole system behind it that should allow you to export whole directories at certain subpaths.
I would like to add a lib in my Nx monorepo which adds type definition (for Typescript) to an existing pure-javascript library (which lives outside the monorepo).
Did anyone already try something like this? Is it possible without a separate project (have the typings outside the monorepo)? Can you point me some examples/litterature?
I naively thought it would have been enough to name the lib #types/scope__the-lib to make everything works (like npm install #types/scope__the-lib adds a folder in node_modules/#types used by typescript as a location of typings files), but I'm missing some parts.
I used to put all my tests together inside of __test__ directory. But I decided to put each test files into each component's directory with different name convention.
Old Structure:
src/
__test__/
example.test.js
example2.test.js
New Structure:
src/
components/
example/
example-controller.js
example-model.js
example-route.js
example-test.js
As naming and location of a directory changed, I updated all import statement and namings for according files. I was using default feature of Jest but since I changed test file name to example-test from example.test I also updated package.json
"jest": {
"testRegex": "./src/components/*/.*.-test.js$"
},
Problem is when I run the project, npm run it throws
beforeAll((0, _asyncToGenerator3.default)( /#PURE/_regenerator2.default.mark(function _callee() {
ReferenceError: beforeAll is not defined
any idea why it is happening?
Try regextester with your file-paths before getting frustrated. Also, look at some popular existing javascript projects using jest and check their jest configurations to see how the community is settling on project structure. It may seem simple to follow others, but most software engineers don't work alone, and usually agree on good practices.
Consider coming back to this project in a year; You are changing the default behavior of a simple process that works beautifully out of the box. Someone may hate you later after a git blame.
If all you want to do is check all -test.js files, slowly modify the default config until you match the file paths you want.
(/__tests__/.*|(\\.|/)(test|spec))\\.[jt]sx?$
Should probably (for you) be:
(.*/src/.*(-test).jsx?)
I have a library coming up deep in the node module hierarchy which is causing security issues. I am not directly referencing that module in my package.json. One of the module which I reference is loading up another module and that module is loading this module. So it's the third layer in the dependency tree. I can find out the library dependence tree using npm ls.
I tried updating package.json, but that's not correct I think.
How can I update the version of this particular module without touching the top modules? Should I have to use shrinkwrap?
One (horrible way) (to answer your question directly) you could carefully manage all of those dependencies on your own and build that structure outside of NPM. I hate it. There is a ton of dependency management overhead and no guarantee any of the hand assembled components would work together - so testing overhead too. but in "theory" it could work. FWIW I don't think shrinkwrap helps with sub dependencies at all.
I recommend this course (I understand this isn't what you asked for - but it is the best approach IMO):
Fork/Branch the library and make the change there.
Then issue a pull request (Back to the main branch)
Until it is is merged back in, you cab reference it via the GIT url in your package.json
from: https://docs.npmjs.com/files/package.json
git+ssh://git#github.com:npm/npm.git#v1.0.27
git+ssh://git#github.com:npm/npm#semver:^5.0
git+https://isaacs#github.com/npm/npm.git
git://github.com/npm/npm.git#v1.0.27
I think it would be great to directly import modules from node_modules directory without need to manually provide a declaration file for it (let us assume that declaration is provided with module itself). I guess that problem are dependencies that come with declarations (file paths could be resolved relative to the module, but that would cause duplicates and compiler can't handle that).
Currently working with node modules is very inconvenient because simple install from npm repository just isn't enough and we have to manually search for declarations and provide them in our project. Let's say that our project is dependent on 10 node modules (all of them have declarations) and after a year we would like to update them. We would have to manually search for new declarations and let's say that we have around 20 projects like this (it would become a nightmare). Maybe there should be an option to directly import .ts file from node module?
Do you have any suggestions?
This is a re-post from CodePlex to hear your opinions ...
If you use grunt-typescript then I've got a pull request which solves this at least for me. See https://github.com/k-maru/grunt-typescript/pull/36
From the pull request README
Working with modules in node_modules (i.e. npm)
The standard way to use npm packages is to provide a definition file
that specifies the package to the typescript and import the module from there.
///<reference path="path/to/mod.d.ts" />
import mod = module('mod')
The typescript compiler will convert the import to a nodejs require.
var mod = require('mod')
This is pretty unwieldy as you need to know the precise path to the
npm installed package and npm can put the package at pretty much any
level when you are working with multiple levels of dependencies.
With the node_modules option in the grunt config you can just
import a npm package without need to know the exact level where the
package has been installed by npm as long as it is installed locally
and not globally.
To import an npm module in your typescript source do
import npmModule = module('node_modules/npmModule/foo')
Mostly due to a lucky chance this works. Typescript compiler will read
the typescript definition file node_modules/npmModule/foo.d.ts if it
is present at some point on the way towards the root and the resulting
javascript file will contain a require for npmModule/foo if needed.
I don't think that node modules will ever contain built-in typescript support. The language still is a 0.x release and officially described as an alpha version.
Nevertheless there are means to ease the configuration process for typescript. Github already contains huge collections of .d.ts files such as:
https://github.com/borisyankov/DefinitelyTyped
or
https://github.com/soywiz/typescript-node-definitions
You might want to take a look at this tool: https://github.com/Diullei/tsd .
I've never used it but it seems like it's almost what you're looking for.
Moreover I've heard that an official database of .d.ts files is planned. Unfortunately I couldn't find the link but it will probably be some time before this is implemented anyways.