lwc
lwc copied to clipboard
Unify compiler and engine packages
In many frameworks, it is common to npm install name-of-framework
and import everything from that one package. For LWC, this would avoid the problem where a consumer of LWC has multiple @lwc/*
/ lwc
packages with conflicting versions.
In short, this would mean making sure that npm install lwc
gives you everything you need to run LWC. There would be no need to install a separate @lwc/compiler
package.
One (simple) way we could solve this would be to just add files like the following to the lwc
package:
// compiler.js
module.exports = require('@lwc/compiler')
// engine-server.js
module.exports = require('@lwc/engine-server')
// rollup-plugin.js
module.exports = require('@lwc/rollup-plugin')
... and then we would add @lwc/compiler
, @lwc/engine-server
, and @lwc/rollup-plugin
(etc.) to the dependencies
of lwc
. So consumers could do:
import compiler from 'lwc/compiler'
import { renderComponent } from 'lwc/engine-server'
import plugin from 'lwc/rollup-plugin'
Some advantages of this approach:
-
lwc
is guaranteed to install the correct version of@lwc/compiler
as itsdependency
. - No breaking changes. You can continue to use
@lwc/compiler
orlwc/compiler
– both work. (If there are multiple conflicting versions installed, then well, you were going to have a bad time anyway.) - We don't have to worry about tree-shaking problems (which would arise from cramming everything into a single
index.js
file) – everything is neatly separated into different files
We could do this in a backwards-compatible way, but it may make more sense to start with a clean slate:
- Using Node.js package exports
- Dropping CommonJS support
- Removing
lwc/index.js
andlwc/types.d.ts
, which don't seem necessary iflwc
is just exporting other packages
I really like this plan!
We can also do https://github.com/salesforce/lwc/issues/2430 while we're at it. lwc
should just be a dumb package that re-exports other packages.
OTOH, https://github.com/salesforce/lwc/issues/2765 and https://github.com/salesforce/lwc/issues/3017 may be a lot harder to accomplish; there are ecosystem issues: https://github.com/salesforce/lwc/issues/3445#issuecomment-1504121029
We should probably also make the default export of lwc
something like:
module.exports = require('@lwc/engine-dom');
Otherwise it's kind of weird to have import { LightningElement } from 'lwc'
, and yet lwc
doesn't actually export that…
This issue has been linked to a new work item: W-13659052
@nolanlawson would you consider exporting the mutation tracker and membrane functionality as well? That would make it much easier under Salesforce environment to integrate custom more complex state management on top of the existing one if we've have access to membranes and their get/set/subscribe functionality. As I checked framework/main.ts does not export anything useful regarding membranes.
@attilah Mutation tracker / observable-membrane are a bit special in that they get directly bundled into engine-dom
/engine-server
. In other words, they aren't dependencies, but rather devDependencies.
What is your use case for importing observable-membrane on its own?