-
Notifications
You must be signed in to change notification settings - Fork 521
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
Regression in 1.6.0 autogenerated test rules #1823
Comments
Must have been introduced in 1.5.0...1.6.0 for each commit, say
note, bazel can't know that the repository rule needs to be re-run so I do a I found the culprit causing the issue was introduced in 5c2f6c1 |
Imported your repro so we see the breakage here in our CI |
Thanks for including the bisect steps. I couldn't figure out how to importted |
On my list for this week. Will get a fix into a 1.6.1 release. |
…when under runfiles Resolves bazel-contrib#1823 which had a repro https://github.com/purkhusid/ts-jest-repro. NB: The repo uses ts_library devmode UMD output so the relative require in the source code will be transformed to an absolute require which will include the workspace name. In 1.5.0: ``` .../sandbox/darwin-sandbox/23/execroot/jest_repro/bazel-out/darwin-fastbuild/bin/test.sh.runfiles/jest_repro/lib.test.js const lib_1 = require("jest_repro/lib"); ``` works as it finds ``` .../sandbox/darwin-sandbox/23/execroot/jest_repro/bazel-out/darwin-fastbuild/bin/test.sh.runfiles/jest_repro/node_modules/jest_repro/lib.js ``` where `test.sh.runfiles/jest_repro/node_modules/jest_repro` is a symlink to the root of the output tree setup by the linker: ``` lrwxr-xr-x 1 greg wheel 165 29 Apr 05:56 .../sandbox/darwin-sandbox/6/execroot/jest_repro/bazel-out/darwin-fastbuild/bin/test.sh.runfiles/jest_repro/node_modules/jest_repro -> .../sandbox/darwin-sandbox/6/execroot/jest_repro/bazel-out/darwin-fastbuild/bin/test.sh.runfiles/jest_repro ``` In 1.6.0: Bug introduced in bazel-contrib#1850 (thanks for tracking down the culprit @alexeagle) where the root symlink is not created properly when under runfiles (such as a jest_test context). Fix is: ``` let runfilesPath = modulePath; if (runfilesPath.startsWith(`${bin}/`)) { runfilesPath = runfilesPath.slice(bin.length + 1); + } else if (runfilesPath === bin) { + runfilesPath = ''; } ``` in `link_node_modules.ts`. NB: This root workspace symlink will be removed in 2.0 as it causes other unrelated issues. PR for that change is in progress bazel-contrib#1797. In 2.0, we recommend either using the prodmode esm output of ts_library for jest_test or switching to ts_project where the output flavor is controlled by your tsconfig. An example of using ts_library esm output of ts_library (output_group 'es6_sources') is `under /internal/linker/test/issue_1823_use_ts_library_esm`. It require babel-jest to transform the esm to commonjs. Alternately, you can control the 'es5_sources' module format of ts_library with the `devmode_module` but this can lead to other issues such as the output no longer being compatible with ts_devserver and karma_web_test which require named-UMD or named-AMD.
…when under runfiles Resolves #1823 which had a repro https://github.com/purkhusid/ts-jest-repro. NB: The repo uses ts_library devmode UMD output so the relative require in the source code will be transformed to an absolute require which will include the workspace name. In 1.5.0: ``` .../sandbox/darwin-sandbox/23/execroot/jest_repro/bazel-out/darwin-fastbuild/bin/test.sh.runfiles/jest_repro/lib.test.js const lib_1 = require("jest_repro/lib"); ``` works as it finds ``` .../sandbox/darwin-sandbox/23/execroot/jest_repro/bazel-out/darwin-fastbuild/bin/test.sh.runfiles/jest_repro/node_modules/jest_repro/lib.js ``` where `test.sh.runfiles/jest_repro/node_modules/jest_repro` is a symlink to the root of the output tree setup by the linker: ``` lrwxr-xr-x 1 greg wheel 165 29 Apr 05:56 .../sandbox/darwin-sandbox/6/execroot/jest_repro/bazel-out/darwin-fastbuild/bin/test.sh.runfiles/jest_repro/node_modules/jest_repro -> .../sandbox/darwin-sandbox/6/execroot/jest_repro/bazel-out/darwin-fastbuild/bin/test.sh.runfiles/jest_repro ``` In 1.6.0: Bug introduced in #1850 (thanks for tracking down the culprit @alexeagle) where the root symlink is not created properly when under runfiles (such as a jest_test context). Fix is: ``` let runfilesPath = modulePath; if (runfilesPath.startsWith(`${bin}/`)) { runfilesPath = runfilesPath.slice(bin.length + 1); + } else if (runfilesPath === bin) { + runfilesPath = ''; } ``` in `link_node_modules.ts`. NB: This root workspace symlink will be removed in 2.0 as it causes other unrelated issues. PR for that change is in progress #1797. In 2.0, we recommend either using the prodmode esm output of ts_library for jest_test or switching to ts_project where the output flavor is controlled by your tsconfig. An example of using ts_library esm output of ts_library (output_group 'es6_sources') is `under /internal/linker/test/issue_1823_use_ts_library_esm`. It require babel-jest to transform the esm to commonjs. Alternately, you can control the 'es5_sources' module format of ts_library with the `devmode_module` but this can lead to other issues such as the output no longer being compatible with ts_devserver and karma_web_test which require named-UMD or named-AMD.
…when under runfiles Resolves bazel-contrib#1823 which had a repro https://github.com/purkhusid/ts-jest-repro. NB: The repo uses ts_library devmode UMD output so the relative require in the source code will be transformed to an absolute require which will include the workspace name. In 1.5.0: ``` .../sandbox/darwin-sandbox/23/execroot/jest_repro/bazel-out/darwin-fastbuild/bin/test.sh.runfiles/jest_repro/lib.test.js const lib_1 = require("jest_repro/lib"); ``` works as it finds ``` .../sandbox/darwin-sandbox/23/execroot/jest_repro/bazel-out/darwin-fastbuild/bin/test.sh.runfiles/jest_repro/node_modules/jest_repro/lib.js ``` where `test.sh.runfiles/jest_repro/node_modules/jest_repro` is a symlink to the root of the output tree setup by the linker: ``` lrwxr-xr-x 1 greg wheel 165 29 Apr 05:56 .../sandbox/darwin-sandbox/6/execroot/jest_repro/bazel-out/darwin-fastbuild/bin/test.sh.runfiles/jest_repro/node_modules/jest_repro -> .../sandbox/darwin-sandbox/6/execroot/jest_repro/bazel-out/darwin-fastbuild/bin/test.sh.runfiles/jest_repro ``` In 1.6.0: Bug introduced in bazel-contrib#1850 (thanks for tracking down the culprit @alexeagle) where the root symlink is not created properly when under runfiles (such as a jest_test context). Fix is: ``` let runfilesPath = modulePath; if (runfilesPath.startsWith(`${bin}/`)) { runfilesPath = runfilesPath.slice(bin.length + 1); + } else if (runfilesPath === bin) { + runfilesPath = ''; } ``` in `link_node_modules.ts`. NB: This root workspace symlink will be removed in 2.0 as it causes other unrelated issues. PR for that change is in progress bazel-contrib#1797. In 2.0, we recommend either using the prodmode esm output of ts_library for jest_test or switching to ts_project where the output flavor is controlled by your tsconfig. An example of using ts_library esm output of ts_library (output_group 'es6_sources') is `under /internal/linker/test/issue_1823_use_ts_library_esm`. It require babel-jest to transform the esm to commonjs. Alternately, you can control the 'es5_sources' module format of ts_library with the `devmode_module` but this can lead to other issues such as the output no longer being compatible with ts_devserver and karma_web_test which require named-UMD or named-AMD.
Thanks for fixing it that quickly! |
It looks like this regressed again in 2.0.0. I created a new issue. #2008 |
Affected Rule
Not so sure if it's only autogenerated rules, but the repro I have is failing in a auto generated test rule.
Is this a regression?
Yes, this works in 1.5.0.
Description
Auto generated rules fails to load resolve module from a relative file during a test run.
🔬 Minimal Reproduction
https://github.com/purkhusid/ts-jest-repro
🔥 Exception or Error
🌍 Your Environment
Operating System:
Output of
bazel version
:Rules_nodejs version:
The text was updated successfully, but these errors were encountered: