You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Publish pre-release versions of TypeScript via npm #964
TypeScript in master contains many new and interesting features. It would be great if pre-release versions could be installed via npm. This would hopefully help get more testing and exposure for these features for downstreams who can tolerate the risks.
We did talk about this somewhat recently. I believe a pending work item was to clarify the npm naming conventions here to ensure that the pre-release packages never interfered with workflows of people who don't want pre-release bits. How often would you expect the pre-release versions to be published? On some regular cadence or like every day/check in automatically?
My understanding of the semver rules is that a prerelease package would be named [major].[minor].[patch]-[prerelease tag] eg. '1.3.0-beta.1' and published to a tag such as 'future' (eg. with 'npm publish --tag future'). By default npm installs the 'latest' tag, so as long as you publish a pre-release with a different tag, users who don't want pre-release builds shouldn't get them. Packages which depend on a pre-release version of TypeScript (eg. with "^1.3.0-beta.4') are only satisfied by pre-releases with the same (major, minor, patch) tuple.
As far as release cadence goes, I think it is a good idea to automate the process - but whether it happens on each check-in, once a day etc. doesn't matter so much - whatever fits in with your CI system. For a typical Github project the easiest place to do it is as part of a Travis CI build triggered by a check-in.
You don't have to publish to the npm registry (or even a private registry) to be able to use it to install packages. npm supports installing from tarballs, and Github generates tarballs for tags. I maintain https://github.com/Arnavion/typescript-github and update it every so often with the build products of latest master. Installing it with npm is just npm install https://github.com/Arnavion/typescript-github/tarball/<release name>
Of course in this repository's case, the automatic tarball will contain the full source whereas consumers of the tarball are just interested in the bin directory. You can have a task in your Jakefile that tags a pre-release but uploads a custom tarball to GH. Alternatively, you can do as I did and make a separate repository and check in just the contents of the bin directory.
Regarding how often to tag and publish, I agree with Masahiro Wakame (@vvakame) that a publish on every LKG update is a good idea.
Activity
danquirk commentedon Oct 27, 2014
We did talk about this somewhat recently. I believe a pending work item was to clarify the npm naming conventions here to ensure that the pre-release packages never interfered with workflows of people who don't want pre-release bits. How often would you expect the pre-release versions to be published? On some regular cadence or like every day/check in automatically?
robertknight commentedon Oct 28, 2014
My understanding of the semver rules is that a prerelease package would be named [major].[minor].[patch]-[prerelease tag] eg. '1.3.0-beta.1' and published to a tag such as 'future' (eg. with 'npm publish --tag future'). By default npm installs the 'latest' tag, so as long as you publish a pre-release with a different tag, users who don't want pre-release builds shouldn't get them. Packages which depend on a pre-release version of TypeScript (eg. with "^1.3.0-beta.4') are only satisfied by pre-releases with the same (major, minor, patch) tuple.
As far as release cadence goes, I think it is a good idea to automate the process - but whether it happens on each check-in, once a day etc. doesn't matter so much - whatever fits in with your CI system. For a typical Github project the easiest place to do it is as part of a Travis CI build triggered by a check-in.
vvakame commentedon Oct 31, 2014
DefinitelyTyped/DefinitelyTyped#3031
I'm expecting publish when LKG is updated.
Arnavion commentedon Nov 14, 2014
You don't have to publish to the npm registry (or even a private registry) to be able to use it to install packages. npm supports installing from tarballs, and Github generates tarballs for tags. I maintain https://github.com/Arnavion/typescript-github and update it every so often with the build products of latest master. Installing it with npm is just
npm install https://github.com/Arnavion/typescript-github/tarball/<release name>Of course in this repository's case, the automatic tarball will contain the full source whereas consumers of the tarball are just interested in the bin directory. You can have a task in your Jakefile that tags a pre-release but uploads a custom tarball to GH. Alternatively, you can do as I did and make a separate repository and check in just the contents of the bin directory.
Regarding how often to tag and publish, I agree with Masahiro Wakame (@vvakame) that a publish on every LKG update is a good idea.
vvakame commentedon Jul 24, 2015
closed by #3875 ?
DanielRosenwasser commentedon Jul 24, 2015
Not just yet; I need to ensure that the nightly build script actually works when it gets triggered before closing.
DanielRosenwasser commentedon Jul 24, 2015
Pretty confident it works so far. The command is
Arnavion commentedon Jul 24, 2015
Daniel Rosenwasser (@DanielRosenwasser) How often are you guys going to publish? Then I can retire my repo :)
DanielRosenwasser commentedon Jul 24, 2015
Arnav Singh (@Arnavion) Nightly :D
Check around midnightish to see the end-of-day build.
dsebastien commentedon Jul 24, 2015
Awesome news :)
robertknight commentedon Jul 25, 2015
Indeed. Thanks so much!