I'm publishing an npm package named foo to the npm registry.
I wrote the package using a compile-to-js language.
For sanity, I put the compiled output into the dist/ folder of the project directory.
My package.json lists the entrypoint as dist/entry.js:
{
"name": "foo",
"main": "dist/entry.js",
}
Sometimes, I want to use files within the package that are not part of the entry point. For example, there is a very useful export called whatever inside of dist/util.js:
import { whatever } from "foo/dist/util";
This works, but forcing the users of my package to type dist/ in all import statements is inconvenient.
Furthermore, re-exporting every possible util function is not DRY. I do not want to re-export from the entrypoint.
Ideally, I would like to import files from dist/ using the following syntax:
import { whatever } from "foo/util"
How do I configure my package.json to search for files in the dist/ folder of my project?
This cannot be done.
This is the reason why some packages have entry point file that re-exports all public exports (not everything that resides in dist is intended to be used by end user), e.g. #angular/core.
And the reason why some packages have unsuitable file structure that is published to NPM registry and favours proper import paths, e.g. rxjs.
Related
I'm trying to create a new NPM package with TypeScript & Node. The package just allows the users to use a data structure I built. I'm trying to figure what is the right entry point (the value of main) should be in my package.json file. As I understand, I'm going to compile the TypeScript files (which are located in src/) into dist/ directory and those files will be actually hosted in NPM.
So should I have index.ts or index.js? If it's index.ts I'll need to compile it as well right? If it's index.js, then I need to point it to dist/? I'm a bit confused about what is the "right"/"convention" way to do it. At the end, I just want users to be able to load the classes I export in my src/mylist.ts file (which being compiled to dist/mylist.js). Do I even need it?
I was reading the How to use the 'main' parameter in package.json? topic, but it only refers to JS project. How should it be in TypeScript?
As typescript is generally compiled before desctibution, you should compile it and use dist/index.js
You will need this do define what import {} from 'my-module' means (i.e. import {} from 'my-module' is threated same as import {} from 'my-module/dist/index.js')
If you don't publish your module and are not using it as a dependency of some other your module you don't need this at all, just make a scripts: { start: "tsx src/index.ts" } or whatever
I am publishing a library to NPM. The library was written in Typescript, and the result of the Typescript compilation is put in a lib/ folder. The main file is an index.ts that exports my public API:
export * from './functions';
export * from './models';
In package.json, I specify:
{"main": "lib/index.js", "types": "lib/index.d.ts", "files": ["lib/**/*"]}
Once my package is published and installed elsewhere, its folder structure is:
lib/
index.js
index.d.ts
functions/
index.ts
my-function.ts
models/
index.ts
my-model.ts
the consumer imports everything from the package root:
import {someFunction, SomeModel} from 'a-library';
This works, but I like the idea of segregating paths. One path for functions, and another for models. Currently if I remove the top-level index, the imports become segregated but they now include the lib/ folder in the path which I don't want:
import {someFunction} from 'a-library/lib/functions';
import {SomeModel} from 'a-library/lib/models';
What I would actually like to accomplish is the same but without lib/. I have a working solution but it seems too convoluted. Here is what works:
In package.json, remove the main types and files key.
Delete or empty the index.ts
To publish replace the simple npm publish with the following steps:
copy package.json and paste it into /lib folder
cd into the /lib folder and run npm pack and take note of the created tarball's name
run npm publish {{TARBALL_NAME}}
cd back up to the project root
As a result, the published package has the following folder structure once installed:
functions/
index.ts
my-function.ts
models/
index.ts
my-model.ts
Because things are no longer nested within a lib/ directory the consumer can import as I wished:
import {someFunction} from 'a-library/functions';
import {SomeModel} from 'a-library/models';
The problem is that packing and publishing to accomplish this seems too cumbersome. I'll never get my teammates to by into a 3 or 4 step process when they've just been running npm publish all this time.
Is there a simpler way to accomplish what I'm after?
My monorepo:
/app1
package.json
/app2
package.json
/shared
package.json
The shared/package.json has "name": "#company/shared".
The app projects' package.json files have dependecy "#company/shared": "file:../shared".
When referencing the shared code, I want a "short" style, which is also less liable to break when things are moved around:
import { foo } from "#company/shared"
But that doesn't work, so I have to do this::
import { foo } from "../../../../../shared/src/something"
I fiddled with both package.json and tsconfig.json without success.
How do I set that up?
You should link your shared package to your dependent packages using npm-link.
cd ~/shared # go into the package directory
npm link # creates global link
cd ~/app1 # go into some other package directory.
npm link #company/shared # link-install the package
this will tell npm to install the package from the shared folder, and update with any changes made to the original package
for more info see https://docs.npmjs.com/cli/link.html
EDIT:
I have realized only now that you are planning to upload the shared package to the server. in that case you may use the module-alias package, https://www.npmjs.com/package/module-alias
this will allow you to make imports such as const sharedModule = require('#shared/moduleName');
EDIT #2:
For typescript, use https://www.npmjs.com/package/tsconfig-paths
Actually there is a part missing from my code above.
The shared project needs to export the shared stuff in an index.js (i.e. a "barrel" file) and reference that in the package.json:
"main": "dist/index.js",
"types": "dist/index.d.ts",
And then the alias import style works.
I have a javascript library that I want to publish on npm: let's call it foo.
The problem is that the javascript files to be consumed by the clients are under a dist folder.
Therefore, for the moment the clients has to include dist in their import statement like this:
import { bar } from 'dist/foo'
I would like to allow clients to import the foo library without mentioning dist explicitly, like this:
import { bar } from 'foo'
Is there a way to add a property in package.json of foo or maybe in the package.json of the clients?
Remark: The reason why the javascript files are in a dist folder is because my library is written in clojurescript. Therefore the source files are under src and the generated files are under dist.
You can add a main section in your package.json :
main: If you have a single module that serves as the entry point to your program (like what the "foo" package gives you at require("foo")), then you need to specify that in the "main" field.
ref: https://docs.npmjs.com/misc/developers
But it will only work for a single file, if you need to require multiple files, you should only publish your dist folder :
npm publish dist
I am using angular-cli for my angular application, but because angular-cli currently does not support use for creating a library, I used the seemingly most widely used git project to create my library: https://github.com/jvandemo/generator-angular2-library
My issue is that I don't want to publish my npm module library to the public directory. Instead I want to use the git url directly in my dependencies. During development, this works fine. I can run the build locally and run an npm link inside the "dist" folder and everything is dandy. However when I push my npm module code to git, and then run an npm install in the consuming project, I'm not sure how to set it so that my consuming project just looks inside the dist folder of the module and treats it as if it was the root of the module.
For example, in node_modules/my_private_module, my file structure looks like:
dist/
-- component1
-- compoennt2
-- my_module.metadata.json
-- my_module.d.ts
-- my_module.umd.js
-- index.d.ts
-- index.js
-- package.json
-- README.MD
package.json
README.md
All the files that my application is using are in the /dist folder, but I DO NOT want to specify "dist" in all my imports like
import { myComponent1 } from 'my_private_module/dist';
I want to be able to just specify
import { myComponent } from 'my_private_module";
As I do in development when I run an npm link in the dist folder.
Is there a way I can achieve this?
Thanks
In package.json for your module, in the root folder:
typings: 'dist/index.d.ts',
main: 'dist/index.js'
Remove the package.json in your dist folder.
When the package is resolved from import {...} from 'my_private_module', the module loader will look for a folder called my_private_module under node_modules, and look either for index.js which defines the exports, or within package.json for the main property - which in your case also points to index.js from the dist folder.
It is good practice to put package.json where you want your module to be found, and have main and typings point to index.js and index.d.ts.
I answered a similar question here and it seems relevant.
Basically, treat the generated library in the dist folder as it's own repo. In order to keep the git init files and folders, you tell ng-packagr to not destroy the destination when building. Then you push the changes to the library specific repo and use that as your package url in other projects.