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.

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

Excess files from ts_library land in pkg_npm #1499

Closed
kylecordes opened this issue Dec 22, 2019 · 4 comments · Fixed by #1677
Closed

Excess files from ts_library land in pkg_npm #1499

kylecordes opened this issue Dec 22, 2019 · 4 comments · Fixed by #1677
Labels

Comments

@kylecordes
Copy link

kylecordes commented Dec 22, 2019

🐞 bug report

Affected Rule

ts_library and/or pkg_npm

Is this a regression?

No, as far as I know, but I did not check previous versions.

Description

I set about building an npm package using Bazel and TypeScript. Following what appeared to be the documented and/or example mechanisms out there, it mostly works, but there seem to be excess files.

🔬 Minimal Reproduction

https://github.com/kylecordes/ts-package-repro

(I am aware that this is so minimal as to be perhaps not be idiomatic in terms of the contents of the generated package containing different ES versions, packagings, etc.)

🔥 Exception or Error

There is no error, but many more files come along from the output of ts_library and land in the pkg_npm generated package than I expect based on examples, documentation, discussion, etc. For example, the .js output from ts_library, various extra .d.ts files under "external".

🌍 Your Environment

Operating System:

OSX Catalina

$ bazel version
Bazelisk version: 56a03d98104be7cfa57d4bbdc03b4c7cea29a6c9
Build label: 2.0.0

(But I saw #1486... so I verified the same output with Bazel 1.2.1.)

Rules_nodejs version:

(Please check that you have matching versions between WORKSPACE file and @bazel/* npm packages.)

  
http_archive(
    name = "build_bazel_rules_nodejs",
    sha256 = "3887b948779431ac443e6a64f31b9e1e17b8d386a31eebc50ec1d9b0a6cabd2b",
    urls = ["https://github.com/bazelbuild/rules_nodejs/releases/download/1.0.0/rules_nodejs-1.0.0.tar.gz"],
)
  

Anything else relevant?

I am not yet 100% familiar with all wrinkles of how rules_nodejs handles package generation, and there are potentially relevant open issues like #1265.

@alexeagle
Copy link
Collaborator

.d.ts outputs are expected. what are the "various extra files under external"? could you include some directory listing of what you are seeing?

maybe pkg_npm is missing some filtering to avoid files outside your repo being copied

@kylecordes
Copy link
Author

In the repro, a very simple pkg_npm target named "example" is built. Its contents are below. I expected to see just the first 2 files and the last 1. All the rest appear superflous.

$ cd bazel-bin/example
$ find . -type f
./example.cjs.js
./package.json
./external/npm/node_modules/@types/node/path.d.ts
./external/npm/node_modules/@types/node/constants.d.ts
./external/npm/node_modules/@types/node/domain.d.ts
./external/npm/node_modules/@types/node/globals.d.ts
./external/npm/node_modules/@types/node/string_decoder.d.ts
./external/npm/node_modules/@types/node/tls.d.ts
./external/npm/node_modules/@types/node/tty.d.ts
./external/npm/node_modules/@types/node/punycode.d.ts
./external/npm/node_modules/@types/node/readline.d.ts
./external/npm/node_modules/@types/node/crypto.d.ts
./external/npm/node_modules/@types/node/trace_events.d.ts
./external/npm/node_modules/@types/node/events.d.ts
./external/npm/node_modules/@types/node/os.d.ts
./external/npm/node_modules/@types/node/buffer.d.ts
./external/npm/node_modules/@types/node/querystring.d.ts
./external/npm/node_modules/@types/node/worker_threads.d.ts
./external/npm/node_modules/@types/node/console.d.ts
./external/npm/node_modules/@types/node/async_hooks.d.ts
./external/npm/node_modules/@types/node/dns.d.ts
./external/npm/node_modules/@types/node/vm.d.ts
./external/npm/node_modules/@types/node/timers.d.ts
./external/npm/node_modules/@types/node/http.d.ts
./external/npm/node_modules/@types/node/http2.d.ts
./external/npm/node_modules/@types/node/stream.d.ts
./external/npm/node_modules/@types/node/inspector.d.ts
./external/npm/node_modules/@types/node/v8.d.ts
./external/npm/node_modules/@types/node/perf_hooks.d.ts
./external/npm/node_modules/@types/node/url.d.ts
./external/npm/node_modules/@types/node/cluster.d.ts
./external/npm/node_modules/@types/node/https.d.ts
./external/npm/node_modules/@types/node/assert.d.ts
./external/npm/node_modules/@types/node/fs.d.ts
./external/npm/node_modules/@types/node/repl.d.ts
./external/npm/node_modules/@types/node/dgram.d.ts
./external/npm/node_modules/@types/node/child_process.d.ts
./external/npm/node_modules/@types/node/zlib.d.ts
./external/npm/node_modules/@types/node/module.d.ts
./external/npm/node_modules/@types/node/ts3.2/globals.d.ts
./external/npm/node_modules/@types/node/ts3.2/util.d.ts
./external/npm/node_modules/@types/node/ts3.2/index.d.ts
./external/npm/node_modules/@types/node/base.d.ts
./external/npm/node_modules/@types/node/process.d.ts
./external/npm/node_modules/@types/node/util.d.ts
./external/npm/node_modules/@types/node/index.d.ts
./external/npm/node_modules/@types/node/net.d.ts
./external/npm/node_modules/typescript/lib/typescriptServices.d.ts
./external/npm/node_modules/typescript/lib/protocol.d.ts
./external/npm/node_modules/typescript/lib/tsserverlibrary.d.ts
./external/npm/node_modules/typescript/lib/typescript.d.ts
./src/greeting.js
./src/greeting.d.ts

(I suppose this distraction is what I deserve for wandering over to the allure of my computer during a break from holiday festivities ;-) )

@mattem
Copy link
Collaborator

mattem commented Jan 18, 2020

Ran in to this - npm deps used by ts_library end up in external/npm. The @bazel/ packages published to npm exhibit this behaviour (noted in @bazel/[email protected])

@kylecordes
Copy link
Author

Happy to hear I was not delirious and the problem is real. Also as linked by @gregmagolan in #1551 (comment)

alexeagle added a commit to alexeagle/rules_nodejs that referenced this issue Feb 28, 2020
…ckage

This logic assumed that package_path was non-empty, but when a pkg_npm rule appears in the workspace root, package_path will be empty string and the startswith guard has no effect.

Fixes bazel-contrib#1499
alexeagle added a commit to alexeagle/rules_nodejs that referenced this issue Feb 28, 2020
…ckage

This logic assumed that package_path was non-empty, but when a pkg_npm rule appears in the workspace root, package_path will be empty string and the startswith guard has no effect.

Fixes bazel-contrib#1499
alexeagle added a commit to alexeagle/rules_nodejs that referenced this issue Feb 28, 2020
…ckage

This logic assumed that package_path was non-empty, but when a pkg_npm rule appears in the workspace root, package_path will be empty string and the startswith guard has no effect.

Fixes bazel-contrib#1499
gregmagolan pushed a commit that referenced this issue Mar 2, 2020
…ckage (#1677)

This logic assumed that package_path was non-empty, but when a pkg_npm rule appears in the workspace root, package_path will be empty string and the startswith guard has no effect.

Fixes #1499
alexeagle added a commit to alexeagle/rules_nodejs that referenced this issue Mar 4, 2020
…ckage

This logic assumed that package_path was non-empty, but when a pkg_npm rule appears in the workspace root, package_path will be empty string and the startswith guard has no effect.

Fixes bazel-contrib#1499
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants