Skip to content
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.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Circular source file mapping dependency on extract-i18n #40408

Closed
1 task done
tsvetomir opened this issue Jan 13, 2021 · 2 comments
Closed
1 task done

Circular source file mapping dependency on extract-i18n #40408

tsvetomir opened this issue Jan 13, 2021 · 2 comments
Assignees
@petebacondarwin
Labels
P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent state: has PR
Milestone
Backlog

Comments

@tsvetomir
Copy link

馃悶 Bug report

Command (mark with an x)

  • extract-i18n

Is this a regression?

Yes, the previous version in which this bug was not present was: 10.x (using ng xi18n --ivy).

Description

Running ng extract-i18n warns about Circular source file mapping dependency (full output below) when the project reference Kendo UI for Angular packages. The packages do not contain source maps.

The warning is not present when runing ng serve and ng build in development or production mode.

馃敩 Minimal Reproduction

  1. Clone https://github.com/tsvetomir/ng11-sourcemaps
  2. Run npm install
  3. Run ng extract-i18n

馃敟 Exception or Error

Warning: ./node_modules/@progress/kendo-angular-common/__ivy_ngcc__/dist/fesm5/index.js
Module Warning (from ./node_modules/@angular-devkit/build-angular/src/extract-i18n/ivy-extract-loader.js):
(Emitted value instead of an instance of Error) Unable to fully load /tmp/ng11-sourcemaps/node_modules/@progress/kendo-angular-common/__ivy_ngcc__/dist/fesm5/index.js for source-map flattening: Circular source file mapping dependency: /tmp/ng11-sourcemaps/node_modules/@progress/kendo-angular-common/__ivy_ngcc__/dist/fesm5/index.js.map -> /tmp/ng11-sourcemaps/node_modules/@progress/kendo-angular-common/__ivy_ngcc__/dist/fesm5/index.js.map

Warning: ./node_modules/@progress/kendo-angular-l10n/__ivy_ngcc__/dist/fesm5/index.js
Module Warning (from ./node_modules/@angular-devkit/build-angular/src/extract-i18n/ivy-extract-loader.js):
(Emitted value instead of an instance of Error) Unable to fully load /tmp/ng11-sourcemaps/node_modules/@progress/kendo-angular-l10n/__ivy_ngcc__/dist/fesm5/index.js for source-map flattening: Circular source file mapping dependency: /tmp/ng11-sourcemaps/node_modules/@progress/kendo-angular-l10n/__ivy_ngcc__/dist/fesm5/index.js.map -> /tmp/ng11-sourcemaps/node_modules/@progress/kendo-angular-l10n/__ivy_ngcc__/dist/fesm5/index.js.map

Warning: ./node_modules/@progress/kendo-angular-upload/__ivy_ngcc__/dist/fesm5/index.js
Module Warning (from ./node_modules/@angular-devkit/build-angular/src/extract-i18n/ivy-extract-loader.js):
(Emitted value instead of an instance of Error) Unable to fully load /tmp/ng11-sourcemaps/node_modules/@progress/kendo-angular-upload/__ivy_ngcc__/dist/fesm5/index.js for source-map flattening: Circular source file mapping dependency: /tmp/ng11-sourcemaps/node_modules/@progress/kendo-angular-upload/__ivy_ngcc__/dist/fesm5/index.js.map -> /tmp/ng11-sourcemaps/node_modules/@progress/kendo-angular-upload/__ivy_ngcc__/dist/fesm5/index.js.map

馃實 Your Environment

Angular CLI: 11.0.6
Node: 10.23.1
OS: linux x64

Angular: 11.0.8
... animations, common, compiler, compiler-cli, core, forms
... localize, platform-browser, platform-browser-dynamic, router
Ivy Workspace: Yes

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1100.6
@angular-devkit/build-angular   0.1100.6
@angular-devkit/core            11.0.6
@angular-devkit/schematics      11.0.6
@angular/cli                    11.0.6
@schematics/angular             11.0.6
@schematics/update              0.1100.6
rxjs                            6.6.3
typescript                      4.0.5

Anything else relevant?
Possibly related:
@petebacondarwin
Copy link
Member

I think this is likely to be an issue with either ngcc or localize (or both) which are part of the main repository. So transferring this issue there.

@petebacondarwin petebacondarwin transferred this issue from angular/angular-cli Jan 13, 2021
@ngbot ngbot bot added this to the needsTriage milestone Jan 13, 2021
@jelbourn jelbourn added the P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent label Jan 13, 2021
@ngbot ngbot bot modified the milestones: needsTriage, Backlog Jan 13, 2021
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Jan 14, 2021
@petebacondarwin
fix(compiler-cli): handle pseudo cycles in inline source-maps
d68569a 
When a source-map has an inline source, any source-map linked from
that source should only be loaded if itself is also inline; it should not
attempt to load a source-map from the file-system. Otherwise we can
find ourselves with inadvertent infinite cyclic dependencies.

For example if a transpiler takes a file (e.g. index.js) and generates
a new file overwriting the original file (but capturing the original
source inline in the new source-map (index.js.map) the source
file loader might read the inline original file (also index.js) and
then try to load the `index.js.map` file from disk - ad infinitum.

Fixes angular#40408
@petebacondarwin petebacondarwin mentioned this issue Jan 14, 2021
Closed
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Jan 15, 2021
@petebacondarwin
fix(compiler-cli): handle pseudo cycles in inline source-maps
b6af801 
When a source-map has an inline source, any source-map linked from
that source should only be loaded if itself is also inline; it should not
attempt to load a source-map from the file-system. Otherwise we can
find ourselves with inadvertent infinite cyclic dependencies.

For example if a transpiler takes a file (e.g. index.js) and generates
a new file overwriting the original file (but capturing the original
source inline in the new source-map (index.js.map) the source
file loader might read the inline original file (also index.js) and
then try to load the `index.js.map` file from disk - ad infinitum.

Fixes angular#40408
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Jan 15, 2021
@petebacondarwin
fix(compiler-cli): handle pseudo cycles in inline source-maps
1bf8489 
When a source-map has an inline source, any source-map linked from
that source should only be loaded if itself is also inline; it should not
attempt to load a source-map from the file-system. Otherwise we can
find ourselves with inadvertent infinite cyclic dependencies.

For example if a transpiler takes a file (e.g. index.js) and generates
a new file overwriting the original file (but capturing the original
source inline in the new source-map (index.js.map) the source
file loader might read the inline original file (also index.js) and
then try to load the `index.js.map` file from disk - ad infinitum.

Fixes angular#40408
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Jan 15, 2021
@petebacondarwin
fix(compiler-cli): handle pseudo cycles in inline source-maps
c0a2aeb 
When a source-map has an inline source, any source-map linked from
that source should only be loaded if itself is also inline; it should not
attempt to load a source-map from the file-system. Otherwise we can
find ourselves with inadvertent infinite cyclic dependencies.

For example if a transpiler takes a file (e.g. index.js) and generates
a new file overwriting the original file (but capturing the original
source inline in the new source-map (index.js.map) the source
file loader might read the inline original file (also index.js) and
then try to load the `index.js.map` file from disk - ad infinitum.

Note that the first call to `loadSourceFile()` is special, since you can
pass in the source-file and source-map contents directly; this is common
if the transpiler has just generated these and saves writing them to disk.
When these are passed into `loadSourceFile()` directly, they are not treated
as "inline" for the purposes described above, since there is no chance of
these "in-memory" source-file and source-map being caught up in a cyclic
dependency.

Fixes angular#40408
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Jan 15, 2021
@petebacondarwin
fix(compiler-cli): handle pseudo cycles in inline source-maps
02ad8f0 
When a source-map has an inline source, any source-map linked from
that source should only be loaded if itself is also inline; it should not
attempt to load a source-map from the file-system. Otherwise we can
find ourselves with inadvertent infinite cyclic dependencies.

For example if a transpiler takes a file (e.g. index.js) and generates
a new file overwriting the original file (but capturing the original
source inline in the new source-map (index.js.map) the source
file loader might read the inline original file (also index.js) and
then try to load the `index.js.map` file from disk - ad infinitum.

Note that the first call to `loadSourceFile()` is special, since you can
pass in the source-file and source-map contents directly; this is common
if the transpiler has just generated these and saves writing them to disk.
When these are passed into `loadSourceFile()` directly, they are not treated
as "inline" for the purposes described above, since there is no chance of
these "in-memory" source-file and source-map being caught up in a cyclic
dependency.

Fixes angular#40408
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Jan 16, 2021
@petebacondarwin
fix(compiler-cli): handle pseudo cycles in inline source-maps
d7edcd4 
When a source-map has an inline source, any source-map linked from
that source should only be loaded if itself is also inline; it should not
attempt to load a source-map from the file-system. Otherwise we can
find ourselves with inadvertent infinite cyclic dependencies.

For example if a transpiler takes a file (e.g. index.js) and generates
a new file overwriting the original file (but capturing the original
source inline in the new source-map (index.js.map) the source
file loader might read the inline original file (also index.js) and
then try to load the `index.js.map` file from disk - ad infinitum.

Note that the first call to `loadSourceFile()` is special, since you can
pass in the source-file and source-map contents directly; this is common
if the transpiler has just generated these and saves writing them to disk.
When these are passed into `loadSourceFile()` directly, they are not treated
as "inline" for the purposes described above, since there is no chance of
these "in-memory" source-file and source-map being caught up in a cyclic
dependency.

Fixes angular#40408
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Jan 16, 2021
@petebacondarwin
fix(compiler-cli): handle pseudo cycles in inline source-maps
806ad70 
When a source-map has an inline source, any source-map linked from
that source should only be loaded if itself is also inline; it should not
attempt to load a source-map from the file-system. Otherwise we can
find ourselves with inadvertent infinite cyclic dependencies.

For example if a transpiler takes a file (e.g. index.js) and generates
a new file overwriting the original file (but capturing the original
source inline in the new source-map (index.js.map) the source
file loader might read the inline original file (also index.js) and
then try to load the `index.js.map` file from disk - ad infinitum.

Note that the first call to `loadSourceFile()` is special, since you can
pass in the source-file and source-map contents directly; this is common
if the transpiler has just generated these and saves writing them to disk.
When these are passed into `loadSourceFile()` directly, they are not treated
as "inline" for the purposes described above, since there is no chance of
these "in-memory" source-file and source-map being caught up in a cyclic
dependency.

Fixes angular#40408
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Jan 16, 2021
@petebacondarwin
fix(compiler-cli): handle pseudo cycles in inline source-maps
5d8ae85 
When a source-map has an inline source, any source-map linked from
that source should only be loaded if itself is also inline; it should not
attempt to load a source-map from the file-system. Otherwise we can
find ourselves with inadvertent infinite cyclic dependencies.

For example if a transpiler takes a file (e.g. index.js) and generates
a new file overwriting the original file (but capturing the original
source inline in the new source-map (index.js.map) the source
file loader might read the inline original file (also index.js) and
then try to load the `index.js.map` file from disk - ad infinitum.

Note that the first call to `loadSourceFile()` is special, since you can
pass in the source-file and source-map contents directly; this is common
if the transpiler has just generated these and saves writing them to disk.
When these are passed into `loadSourceFile()` directly, they are not treated
as "inline" for the purposes described above, since there is no chance of
these "in-memory" source-file and source-map being caught up in a cyclic
dependency.

Fixes angular#40408
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Jan 17, 2021
@petebacondarwin
fix(compiler-cli): handle pseudo cycles in inline source-maps
b62779d 
When a source-map has an inline source, any source-map linked from
that source should only be loaded if itself is also inline; it should not
attempt to load a source-map from the file-system. Otherwise we can
find ourselves with inadvertent infinite cyclic dependencies.

For example, if a transpiler takes a file (e.g. index.js) and generates
a new file overwriting the original file - capturing the original
source inline in the new source-map (index.js.map) - the source
file loader might read the inline original file (also index.js) and
then try to load the `index.js.map` file from disk - ad infinitum.

Note that the first call to `loadSourceFile()` is special, since you can
pass in the source-file and source-map contents directly as in-memory
strrngs. This is common if the transpiler has just generated these and has
not yet written them to disk.
When the contents are passed into `loadSourceFile()` directly, they are
not treated as "inline" for the purposes described above since there is
no chance of these "in-memory" source and source-map contents being caught
up in a cyclic dependency.

Fixes angular#40408
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Jan 17, 2021
@petebacondarwin
fix(compiler-cli): handle pseudo cycles in inline source-maps
a79bfe1 
When a source-map has an inline source, any source-map linked from
that source should only be loaded if itself is also inline; it should not
attempt to load a source-map from the file-system. Otherwise we can
find ourselves with inadvertent infinite cyclic dependencies.

For example, if a transpiler takes a file (e.g. index.js) and generates
a new file overwriting the original file - capturing the original
source inline in the new source-map (index.js.map) - the source
file loader might read the inline original file (also index.js) and
then try to load the `index.js.map` file from disk - ad infinitum.

Note that the first call to `loadSourceFile()` is special, since you can
pass in the source-file and source-map contents directly as in-memory
strrngs. This is common if the transpiler has just generated these and has
not yet written them to disk.
When the contents are passed into `loadSourceFile()` directly, they are
not treated as "inline" for the purposes described above since there is
no chance of these "in-memory" source and source-map contents being caught
up in a cyclic dependency.

Fixes angular#40408
petebacondarwin added a commit to petebacondarwin/angular that referenced this issue Jan 20, 2021
@petebacondarwin
fix(compiler-cli): handle pseudo cycles in inline source-maps
1b4226d 
When a source-map has an inline source, any source-map linked from
that source should only be loaded if itself is also inline; it should not
attempt to load a source-map from the file-system. Otherwise we can
find ourselves with inadvertent infinite cyclic dependencies.

For example, if a transpiler takes a file (e.g. index.js) and generates
a new file overwriting the original file - capturing the original
source inline in the new source-map (index.js.map) - the source
file loader might read the inline original file (also index.js) and
then try to load the `index.js.map` file from disk - ad infinitum.

Note that the first call to `loadSourceFile()` is special, since you can
pass in the source-file and source-map contents directly as in-memory
strrngs. This is common if the transpiler has just generated these and has
not yet written them to disk.
When the contents are passed into `loadSourceFile()` directly, they are
not treated as "inline" for the purposes described above since there is
no chance of these "in-memory" source and source-map contents being caught
up in a cyclic dependency.

Fixes angular#40408
jessicajaniuk pushed a commit that referenced this issue Jan 21, 2021
@petebacondarwin @thePunderWoman
fix(compiler-cli): handle pseudo cycles in inline source-maps (#40435)
566206b 
When a source-map has an inline source, any source-map linked from
that source should only be loaded if itself is also inline; it should not
attempt to load a source-map from the file-system. Otherwise we can
find ourselves with inadvertent infinite cyclic dependencies.

For example, if a transpiler takes a file (e.g. index.js) and generates
a new file overwriting the original file - capturing the original
source inline in the new source-map (index.js.map) - the source
file loader might read the inline original file (also index.js) and
then try to load the `index.js.map` file from disk - ad infinitum.

Note that the first call to `loadSourceFile()` is special, since you can
pass in the source-file and source-map contents directly as in-memory
strrngs. This is common if the transpiler has just generated these and has
not yet written them to disk.
When the contents are passed into `loadSourceFile()` directly, they are
not treated as "inline" for the purposes described above since there is
no chance of these "in-memory" source and source-map contents being caught
up in a cyclic dependency.

Fixes #40408

PR Close #40435
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Feb 21, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@petebacondarwin petebacondarwin

Labels
P3 An issue that is relevant to core functions, but does not impede progress. Important, but not urgent state: has PR
Projects
None yet
Milestone
Backlog
Development

Successfully merging a pull request may close this issue.

fix(compiler-cli): handle pseudo cycles in inline source-maps petebacondarwin/angular
3 participants
@petebacondarwin @tsvetomir @jelbourn