![]() As a result, the output is efficiently constrained just to what is actually necessary, yielding a smaller bundle size as a result. When we import a typescripe type, using an import type statement allows rollup to ensure it is only importing the type definitions from the file, without importing the actual source code implementations. This allows our bundler, rollup, to minimize the amount of code it needs to pull in when resolving the import. ![]() When we need to import source code, like a function or a constant, we import it using a path import, making sure that the file that is imported from has as little other code as possible by breaking up our code into many files. Here's a snippet of the imports from our n entrypoint. This worked great both in development for publishing the bundle to npm, until we noticed that our n npmjs package had a large bundle size as it was bundling the entire codebase of The SolutionĪfter a bit of trial and error, we arrived at a solution: use relative path imports and rely on code splitting and type imports. We replaced imports of with relative paths like. Next, we tried to use relative imports to make sure that the bundle didn't have any references to the private package. Just like with the frontend usage of n, we started with having n import from client by referencing the package.json name of This successfully worked in development as the reference could be resolved, but when we built n for production, the bundle contained references to which could not be resolved in our customers' environments since it was not a published package. Though n references typescript type definitions from client, we also don't want to bundle most of the code into n as that would increase the bundle size (instead we have n inject client as a deffered tag at browser runtime see more as to why in our performance docs). While we want to publish n to npm, we don't want to publish the client library. There's a bit of a catch here though: our n library uses our internal client typescript package that isn't public. That setup sounded simple, right? Just write JS/TS, reference other local packages as you would if they were imported from npm, and you can publish your library. That's all Publishing an NPM package with workspace dependencies because that directory is part of the workspaces key and has the corresponding name in its package.json.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |