-
Notifications
You must be signed in to change notification settings - Fork 392
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: use consistent build process across packages #3456
Conversation
BREAKING CHANGE
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This script is the main magic; everything else is basically just details.
}, | ||
"namedInputs": { | ||
"sharedGlobals": ["{workspaceRoot}/scripts/rollup/rollup.config.js"], | ||
"default": ["{projectRoot}/**/*", "sharedGlobals"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This tells NX that when this file changes, it should bust the cache
@@ -29,6 +29,9 @@ export function parse(source: string, config: Config = {}): TemplateParseResult | |||
return parseTemplate(source, state); | |||
} | |||
|
|||
// Export as a named export as well for easier importing in certain environments (e.g. Jest) | |||
export { compile }; | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I needed this to unbreak our Jest tests. Jest is weird about default exports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if this will break anything else in the DX ecosystem, if they import @lwc/template-compiler
directly. I'm fine with this change, but we should keep an eye out for issues that might arise because of this change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm hoping we'll be fine, and that this is just an internal issue with TypeScript+Jest on our source code, but it's impossible to know for sure.
FWIW the current package uses exports.default = compile
in the dist
CJS file, and the new dist
file does the same thing.
"devDependencies": { | ||
"@lwc/engine-core": "2.43.0", | ||
"@lwc/shared": "2.43.0" | ||
}, | ||
"lwc": { | ||
"modules": [ | ||
{ | ||
"name": "wire-service", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Technically I'm breaking import 'wire-service'
, but we shouldn't support this anyway because of dependency confusion. (Luckily we are not vulnerable because we squatted the package.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also I doubt anybody is using this.
@@ -15,7 +15,7 @@ function createDir(dir) { | |||
} | |||
|
|||
function getEs6ModuleEntry(pkg) { | |||
const pkgFilePath = require.resolve(`${pkg}/package.json`); | |||
const pkgFilePath = path.resolve(__dirname, '../../../', pkg, './package.json'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed this because originally I was using package exports, which breaks if you try to require an unexposed file. I think it's better to just use path.resolve
anyway though.
No more breakages! |
Update: no more breakages!
|
A lot of nice changes in here, should we separate out the non-breaking changes from the breaking changes so that the non-breaking ones are not held up here? |
I was thinking the same thing, yeah. I can rework this so that there are no breaking changes, and then add TODOs for the breaking changes. |
154 lines of code removed! I'm happy about this. @ekashida The breaking changes have been removed – at least, downstream Nucleus tests are passing. Can you take another look? |
@@ -11,7 +11,7 @@ yarn add --dev @lwc/template-compiler | |||
## Usage | |||
|
|||
```js | |||
import compile from '@lwc/template-compiler'; | |||
import { compile } from '@lwc/template-compiler'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Named exports are way more compatible across the JS ecosystem than default exports. We should just recommend people to use this, even if we still support the default exports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fantastic!
packages/@lwc/features/src/index.ts
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also cleanup?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The root source file of each package is now named index.js
. @lwc/features
was inconsistent – its root source file was called flags.ts
.
@@ -29,6 +29,9 @@ export function parse(source: string, config: Config = {}): TemplateParseResult | |||
return parseTemplate(source, state); | |||
} | |||
|
|||
// Export as a named export as well for easier importing in certain environments (e.g. Jest) | |||
export { compile }; | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering if this will break anything else in the DX ecosystem, if they import @lwc/template-compiler
directly. I'm fine with this change, but we should keep an eye out for issues that might arise because of this change.
Boom! 💥 |
Sorry for the late review. This is awesome, thanks! |
"license": "MIT", | ||
"scripts": { | ||
"build": "rollup --config ./scripts/rollup/rollup.config.js", | ||
"postbuild": "node ../../../scripts/tasks/verify-treeshakable.js ./dist/index.js", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Accidentally removed this
Details
Partially addresses #3445
Does this pull request introduce a breaking change?
Update: breaking changes have been removed! I've added backwards compat for usages like this:
I've also added a
TODO
so that hopefully we can remove this when we're ready to release LWC v3.0.0.Does this pull request introduce an observable change?
The
dist/
files have changed, and some exports have been added, so it may be detectable in certain use cases. But this is not detectable to LWC component authors on core – only to npm package consumers.