-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
Update @vercel/ncc
to v0.29.2
#6605
Conversation
@vercel/ncc
to v0.29.1@vercel/ncc
to v0.29.2
Codecov Report
@@ Coverage Diff @@
## main #6605 +/- ##
==========================================
+ Coverage 12.53% 13.39% +0.85%
==========================================
Files 265 265
Lines 9637 9758 +121
Branches 1726 1664 -62
==========================================
+ Hits 1208 1307 +99
- Misses 8330 8362 +32
+ Partials 99 89 -10
Continue to review full report at Codecov.
|
const args = [ | ||
'ncc', | ||
'build', | ||
'--no-asset-builds', |
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.
Needed to enable this new flag to prevent builder-worker.js
and vercel/fun runtimes-related .js
files from being compiled by ncc.
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.
Will post a PR to track possibly disabling this feature by default.
// A bunch of source `.ts` files from CLI's `util` directory | ||
await remove(join(dirRoot, 'dist', 'util')); | ||
// Band-aid to bundle stuff that `ncc` neglects to bundle | ||
await cpy(join(dirRoot, 'src/util/projects/VERCEL_DIR_README.txt'), distRoot); |
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.
For some reason, the VERCEL_DIR_README.txt
file is not being included in the ncc output dir 🤔
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.
Oh I see, it is passed to readFile here:
vercel/packages/cli/src/util/projects/link.ts
Lines 234 to 237 in ee9a8a0
await writeFile( | |
join(path, VERCEL_DIR, VERCEL_DIR_README), | |
await readFile(join(__dirname, 'VERCEL_DIR_README.txt'), 'utf8') | |
); |
So that does seem like a bug.
Thoughts @guybedford ?
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.
In package/cli/src/util/projects/link.ts
you're using __dirname
in an ES module and __dirname
isn't defined in ES modules.
I think you should rather do something like await readFile(new URL('VERCEL_DIR_README.txt', import.meta.url))
.
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 package cli
is using target: commonjs
so I don't think we should use ESM import. I know that __dirname
would work with tsc
so I think it should work with ncc
too.
vercel/packages/cli/tsconfig.json
Line 7 in aca42b2
"module": "commonjs", |
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.
Ok that seemed to work (d617e80). However I had to add a global definition for the url
property otherwise I was hitting error:
error: TS2339 [ERROR]: Property 'url' does not exist on type 'ImportMeta'.
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.
Yeah unfortunately TypeScript are dragging their feet on ESM conventions as usual.
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 reverted it actually cause it was causing an error in the unit tests. Will look into it again in a separate PR.
@@ -19,7 +19,7 @@ import { BuilderWithPackage } from './types'; | |||
|
|||
type CliPackageJson = typeof cliPkg; | |||
|
|||
declare const __non_webpack_require__: typeof require; | |||
const require_: typeof require = eval('require'); |
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.
Is this the most "sanctioned" way (as far as ncc is concerned) to get access to the real require()
function?
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.
eval('require')
is literally what I would recommend yes. In general eval()
as the way around ncc has sort of become a pattern as anything else is game for ncc. For this reason specifically we don't actually eval eval although we could...
@@ -355,8 +355,8 @@ export async function getBuilder( | |||
|
|||
try { | |||
output.debug(`Requiring runtime: "${requirePath}"`); | |||
const mod = require(requirePath); | |||
const pkg = require(join(requirePath, 'package.json')); | |||
const mod = require_(requirePath); |
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.
Previous versions of ncc would allow dynamic require calls to still work, but as of this version of ncc it throws a webpack-specific "Module not found" error, so using the native require()
function was necessary.
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.
Unknown requires should delegate to the environment require. But Webpack is a moving target too in ensuring the invariants here. I will follow up with an ncc issue.
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.
Was trying to replicate this and couldn't then realised this is the same issue - this is a TS ESM file so "require" is not defined.
Rather use dynamic import
or createRequire
to do a dynamic require / import from an ES module.
@@ -1,7 +1,7 @@ | |||
{ | |||
"type": "module", | |||
"dependencies": { | |||
"@lit-labs/ssr": "1.0.0-rc.1", | |||
"lit": "2.0.0-rc.2" | |||
"@lit-labs/ssr": "1.0.0-rc.2", |
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.
Unrelated to the ncc update itself, but this fixture's deps had a transient dependency updated that was published broken to npm. Updated the deps here and added a lockfile to prevent that from happening in the future.
@@ -8,6 +8,7 @@ | |||
"outDir": "dist", | |||
"sourceMap": false, | |||
"declaration": true, | |||
"moduleResolution": "node", |
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.
Latest version of ncc (correctly) complained about this missing prop. All other packages have it already.
@@ -86,7 +86,8 @@ function getVercelLauncher({ | |||
if (shouldAddHelpers) { | |||
bridge.setStoreEvents(true); | |||
import(helpersPath).then(helper => { | |||
const server = helper.createServerWithHelpers(listener, bridge); | |||
const h = helper.default || helper; | |||
const server = h.createServerWithHelpers(listener, bridge); |
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 curious, was this changed because the ncc output of helpers
changed? Maybe we shouldn't use default export for the helpers?
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 didn't really understand this change either. Could be related to Node.js version, because I didn't need this change locally, but on CI it was failing and I needed to check for default
in that case.
Not using We're not actually using default export or default
export is an interesting idea though.module.exports
in this case…
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 only reason I can think this would happen is if helpers is being built into CommonJS as a separate file, and is not part of the ncc build here. Hence for Node.js versions without named exports support for CommonJS it could fail.
If it is referencing the original TS build file as a reference outside of the build, the fix would be to build into ESM not CJS.
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.
And if the above assumption is correct, then the helper.default
should work in all cases and the || helper
fallback shouldn't be necessary.
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.
Would still be curious how this one works out with const h = helper.default;
.
const _require = | ||
typeof __non_webpack_require__ === 'function' | ||
? __non_webpack_require__ | ||
: require; |
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 would expect this to still work since ncc is using webpack under the hood.
Maybe @guybedford could explain why it doesn't work?
Perhaps it should be __nccwpck_require__
instead?
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 part still works, but is unnecessary because of the eval('require')
version.
This reverts commit d617e80.
No description provided.