Typescript: In the typescript-3.3.3333 npm package, two dotfiles accidentally? included

Created on 25 Feb 2019  Β·  16Comments  Β·  Source: microsoft/TypeScript


TypeScript Version: 3.3.3333


Search Terms: gitdir shared worktrees TypeScript3

Code (shell conversation)

$ npm pack '[email protected]'
npm notice
npm notice [email protected]
npm notice === Tarball Contents ===
npm notice 3.6kB   package.json
npm notice 44.3kB  .failed-tests                 <<==   here
npm notice 66B     .git                          <<==  and here
npm notice 6.1kB   AUTHORS.md
npm notice 333B    CODE_OF_CONDUCT.md
npm notice 819B    CopyrightNotice.txt
npm notice 9.2kB   LICENSE.txt
npm notice 4.9kB   README.md
npm notice 37.8kB  ThirdPartyNoticeText.txt
npm notice 45B     bin/tsc
npm notice 50B     bin/tsserver
npm notice 3.0kB   lib/cancellationToken.js
npm notice 156.7kB lib/cs/diagnosticMessages.generated.json
npm notice 171.3kB lib/de/diagnosticMessages.generated.json
npm notice 145.5kB lib/diagnosticMessages.generated.json
npm notice 168.2kB lib/es/diagnosticMessages.generated.json
npm notice 169.4kB lib/fr/diagnosticMessages.generated.json
npm notice 169.0kB lib/it/diagnosticMessages.generated.json
npm notice 191.4kB lib/ja/diagnosticMessages.generated.json
npm notice 172.7kB lib/ko/diagnosticMessages.generated.json
npm notice 1.0kB   lib/lib.d.ts
npm notice 703.0kB lib/lib.dom.d.ts
====
(snip)
====
npm notice 7.0MB   lib/typescriptServices.js
npm notice 16.8kB  lib/typesMap.json
npm notice 5.4MB   lib/typingsInstaller.js
npm notice 1.1kB   lib/watchGuard.js
npm notice 147.1kB lib/zh-cn/diagnosticMessages.generated.json
npm notice 145.1kB lib/zh-tw/diagnosticMessages.generated.json
npm notice === Tarball Details ===
npm notice name:          typescript
npm notice version:       3.3.3333
npm notice filename:      typescript-3.3.3333.tgz
npm notice package size:  7.7 MB
npm notice unpacked size: 43.0 MB
npm notice shasum:        171b2c5af66c59e9431199117a3bcadc66fdcfd6
npm notice integrity:     sha512-JjSKsAfuHBE/f[...]0GDzcJrekZYLw==
npm notice total files:   79
npm notice
typescript-3.3.3333.tgz
$ gunzip -c < typescript-3.3.3333.tgz | tar -Oxf - package/.git
gitdir: /home/daniel/shared/TypeScript/.git/worktrees/TypeScript3

Expected behavior: These two files wouldn't be included.

Actual behavior:

Playground Link:

Related Issues: https://github.com/Microsoft/TypeScript/issues/30032

Bug Fixed Infrastructure

Most helpful comment

FYI: this is breaking Jenkins projects which have the "Clean before checkout" option enabled because it tries to delete such repo:

Caused by: hudson.plugins.git.GitException: Command "/usr/bin/git clean -fdx" returned status code 128:
stdout: 
stderr: fatal: Not a git repository: /home/daniel/shared/TypeScript/.git/worktrees/TypeScript3

All 16 comments

Ugh. Okay, so two things:

  1. .failed-tests is a legitimate issue on us. We likely should've run a clean build beforehand, but we should also ignore that file.
  2. .git is supposed to be a ignored by npm, but apparently not when you're using git worktrees. I'd say this is a bug on npm, but it's honestly easier to add it to the .npmignore as well.

Correction, .git is ignored as a file in newer versions of npm, but it still wouldn't hurt to mark it.

FYI: this is breaking Jenkins projects which have the "Clean before checkout" option enabled because it tries to delete such repo:

Caused by: hudson.plugins.git.GitException: Command "/usr/bin/git clean -fdx" returned status code 128:
stdout: 
stderr: fatal: Not a git repository: /home/daniel/shared/TypeScript/.git/worktrees/TypeScript3

Hi, We are having the same issue with release 2.7.2. We are not planning to updgrae to Typescript 3. Can you help us with this?

Up grade to git 2+ solved our problem

The 3.3.3333 version package is still on npm as the most recent version. It's still breaking things, can we get a release of 3.3.3334 please.

I would say as a workaround just stick to 3.3.3 since the differences are minimal. We'll also have 3.4.0-rc out tomorrow if that works.

How can this still not be fixed? Ran into problems now.

@DanielRosenwasser that's not really how npm packages & semver works - by default 3.3.3333 is being installed instead because it's the highest patch version.

Please publish 3.3.3334 without the .git directory to resolve this issue, it would be super helpful and should only take a few minutes.

@metanest You can use npm pack --dry-run to see the files that will get published without creating a tarball.

@DanielRosenwasser It seems that npm's default ignore list is not always respected. I submitted a PR but there has been little movement πŸ€·β€β™‚οΈ https://github.com/npm/npm-packlist/pull/14#issuecomment-434421930

  1. I highly recommend the package.json "files" key, for specifying a whitelist instead of a blacklist.
    Totally allowed me to leave .npmignore nightmares in the past, regardless of complicated builds.
  2. Not relevant to the thing that happened this time, but I also suggest looking at integrating package-preview into your testing to make sure that you include enough into the tarball.

Apparently Azure Pipelines allows us to create a tarball we can easily try out prior to a publish. I believe @weswigham set this up for us but I'm not sure what he used.

@typescript-bot pack this (in a PR)

The versioning seems to be going all over the place, even after the initial backlash. Can we please stick to incrementing versions by one please?

Can we please stick to incrementing versions by one please?

It _would_ be great if we could just have TS v1237 (that's the number of versions we have published to npm) and drop the idea that the major, minor, or patch releases have strong reasoning behind them. Sadly, adoption of the monotonically increasing build number scheme is difficult in the node community, since the semver default makes people wary of "major" revisions.

(Yeah, I know you meant patch - but we've never actually consistently issued a consecutive series for the patch number - minimally we usually skip .0 and in the past we've skipped other versions, too (to reserve them for drops we only distributed internally) - that these bigger jumps get more attention is quite literally just because the number is bigger)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jbondc picture jbondc  Β·  3Comments

MartynasZilinskas picture MartynasZilinskas  Β·  3Comments

CyrusNajmabadi picture CyrusNajmabadi  Β·  3Comments

Antony-Jones picture Antony-Jones  Β·  3Comments

manekinekko picture manekinekko  Β·  3Comments