modular build <library>
#195
Conversation
…as opposed to apps). It uses rollup to generate commonjs and esm builds of the workspace it's pointing to (based on the `main` field in the workspace's `package.json`), and then generates typescript typings for the same. It then generates a publishable folder under `dist/<workspace name>`, with a modified `package.json` that points to these built versions of the files. The folder will also contain any other files specified by the `files` field, and/or `.npmignore` in the workspace. This is a port of the script we used internally at JPM for the same, and makes it a first class feature for modular. It's fast and works fairly well.
🦋 Changeset detectedLatest commit: 282a106 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
packages/modular-scripts/src/cli.ts
Outdated
| @@ -12,7 +12,7 @@ import { | |||
| } from 'change-case'; | |||
| import prompts from 'prompts'; | |||
| import resolveAsBin from 'resolve-as-bin'; | |||
|
|
|||
| import buildPackage from './build'; | |||
There was a problem hiding this comment.
Build does a lot of top level work - so potentially we want to hide this import or change the top level work done?
There was a problem hiding this comment.
I didn't understand this comment, could you clarify what you mean? Do you want me to move build() into this file?
There was a problem hiding this comment.
My main concern is that there are import side-effects for build.ts e.g. [1] / [2] which do a lot of FS operations. On a machine with a slow-FS (e.g. network drives) this could slow down the startup of the cli for all operations. I think we should either:
- Remove the globals from the
build.tsscript and have them as locals for the build operations, or. - Lazily import
build.tsso that the initialisation only happens when it's needed.
[1] https://github.com/jpmorganchase/modular/pull/195/files#diff-a3c185d299c664d2bc8bbc2bbade48ca2a96a5ed03c585d268e5290e97016c0aR77
[2] https://github.com/jpmorganchase/modular/pull/195/files#diff-a3c185d299c664d2bc8bbc2bbade48ca2a96a5ed03c585d268e5290e97016c0aR96
There was a problem hiding this comment.
Good points. Ok lemme rewrite this.
There was a problem hiding this comment.
Ok this import is now deferred till the time it's actually called.
…o rollup's globals anymore.
This PR adds a feature to let modular build workspaces as libraries (as opposed to only apps). It uses rollup to generate commonjs and esm builds of the workspace it's pointing to (based on the
mainfield in the workspace'spackage.json), and then generates typescript typings for the same. It then generates a publishable folder underdist/<workspace name>, with a modifiedpackage.jsonthat points to these built versions of the files. The folder will also contain any other files specified by thefilesfield, and/or.npmignorein the workspace. Passing--preserve-modulesdecides whether or not to make a bundle.You can also do parallel builds by passing a comma-separated list of packages:
modular build app1,app2,package1,view1,etcFinally, I made it so app builds go to
/dist/<app-name>, for consistency.This is a port of the script we used internally at JPM for the same, and makes it a first class feature for modular. It's fast and works fairly well.
Three things missing from this:
I'll do these in the next PR.