bug: dist/esm/polyfills is empty #4661
Comments
|
Hey @AnnaHoege, thanks for filing this issue! I wasn't able to reproduce it on macOS, but then I tried out your reproduction in a windows 11 VM and, lo and behold, it does reproduce there, so I think we've got a windows-specific bug on our hands here. I'm going to label it to get it ingested into our internal backlog so it can be prioritized and fixed. |
alicewriteswrongs
added
the
Bug: Validated
|
I'm seeing this intermittently on my Windows 11 machine. |
|
Here is my workaround for now using rimraf and a prebuild step. In your package.json add a prebuild which will run before stencil build
|
|
Can anyone running into this issue please try out this dev build for me and let me know if this works? Thanks! |
|
Hi, Works on my side, the polyfills folder is not empty anymore and contains: Thanks for handling it. |
in #4317 (b042d8b), a polyfill for node's `path.join` was [removed](https://github.com/ionic-team/stencil/pull/4317/files#diff-734f69edf83052dfd5ce6df10429550680537c6da66ef9b7cfbda11efdff5117L36), but wasn't backfilled with stencil's `@utils` package version in `generate-esm.ts`. without this change, the destination computed for the polyfills is not normalized for users of Windows OS's. when the destination path is not normalized here (but is normalized in other parts of the code), it creates a situation where stencil's in memory-fs both: 1. marks the polyfills to be copied 2. marks the _previous_ polyfills to be removed normally, if we're performing a copy operation, we don't bother with the deletion (as the copy overwrites the existing polyfills). this is important, as stencil performs its copy operations before it performs its deletions. to ensure that a recently copied file is not subsequently deleted, stencil performs a [check on the files it will delete and removes them from the 'to delete' list](https://github.com/ionic-team/stencil/blob/15a7f89f677bad012dd82a088ce64149a7e48a61/src/compiler/sys/in-memory-fs.ts#L1250-L1253) based on the destination filename. since the destination filename on windows is not normalized and the filename for the same file to delete is (normalized), the check fails to acknowledge we're going to copy this file. this causes the following behavior on a stencil build: - if the polyfills directory exists, mark it to be copied, but subsequently delete it - if the polyfills directory does not exist, mark it to be copied. it will not be marked to be deleted because it does not exist on disk when the list of files to delete is calculated (prior to the copy) Fixes: #4661 STENCIL-918
in #4317 (b042d8b), a polyfill for node's `path.join` was [removed](https://github.com/ionic-team/stencil/pull/4317/files#diff-734f69edf83052dfd5ce6df10429550680537c6da66ef9b7cfbda11efdff5117L36), but wasn't backfilled with stencil's `@utils` package version in `generate-esm.ts`. without this change, the destination computed for the polyfills is not normalized for users of Windows OS's. when the destination path is not normalized here (but is normalized in other parts of the code), it creates a situation where stencil's in memory-fs both: 1. marks the polyfills to be copied 2. marks the _previous_ polyfills to be removed normally, if we're performing a copy operation, we don't bother with the deletion (as the copy overwrites the existing polyfills). this is important, as stencil performs its copy operations before it performs its deletions. to ensure that a recently copied file is not subsequently deleted, stencil performs a [check on the files it will delete and removes them from the 'to delete' list](https://github.com/ionic-team/stencil/blob/15a7f89f677bad012dd82a088ce64149a7e48a61/src/compiler/sys/in-memory-fs.ts#L1250-L1253) based on the destination filename. since the destination filename on windows is not normalized and the filename for the same file to delete is (normalized), the check fails to acknowledge we're going to copy this file. this causes the following behavior on a stencil build: - if the polyfills directory exists, mark it to be copied, but subsequently delete it - if the polyfills directory does not exist, mark it to be copied. it will not be marked to be deleted because it does not exist on disk when the list of files to delete is calculated (prior to the copy) Fixes: #4661 STENCIL-918
|
Starting at ~3AM UTC (tomorrow), the fix for this issue will be a part of the Stencil nightly builds. You can test it out with: We plan on shipping this fix in our next release of Stencil, which is currently planned for no later than 1 week from today. |
|
The fix for this issue has been released as a part of today's Stencil v4.6.0 release |
Prerequisites
Stencil Version
v4.0.4
Current Behavior
When running
npm run build, the resulting dist/esm/polyfills folder is empty every other time the command is run. This causes issues as the loader exports the index file of the polyfills folder.Expected Behavior
The polyfills folder should contain at least an index file on every build.
System Info
System: node 18.17.0 Platform: windows (10.0.19045) CPU Model: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz (8 cpus) Compiler: C:\Users\AHOEGE\Projects\stencil-bug-reproduction\bug-reproduction\node_modules\@stencil\core\compiler\stencil.js Build: 1691405536 Stencil: 4.0.4 TypeScript: 5.0.4 Rollup: 2.42.3 Parse5: 7.1.2 Sizzle: 2.42.3 Terser: 5.19.2Steps to Reproduce
npm init stencilnpm inpm buildnpm buildCode Reproduction URL
https://github.com/AnnaHoege/stencil-bug-reproduction
Additional Information
No response
The text was updated successfully, but these errors were encountered: