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

Prepare for/export to npmjs.com #31

Closed
BurtHarris opened this issue Oct 5, 2016 · 2 comments
Closed

Prepare for/export to npmjs.com #31

BurtHarris opened this issue Oct 5, 2016 · 2 comments

Comments

@BurtHarris
Copy link
Collaborator

There are some change we should probably make in the project.json file so that npm will know about our package. Once that is done, I think we'll be able to use npm link to simplify referring to the package for debugging, samples, etc. And the import directives can avoid some or all of the ..\ prefixes.

I've never done this before, so learning curve is probably about the same for either of us.

@BurtHarris
Copy link
Collaborator Author

BurtHarris commented Oct 26, 2016

  • Copyrighght/license. Fix copyright headers and notice prior to public repository #94 should probably be addressed before we start publishing files in NPM.
  • Do we want to setup a "antlr4" npm organization to own this. Note: ericvergnaud an antlr4 runtime under his own name about 6 months ago. Existing ANTLR4 related packages on npm
  • Naming. I assume we'll stick with the base name: antlr4ts. The only heartburn I have with this is that the "4ts" might suggest to some that you have to write TypeScript to make use of it, when I think that having the become the default antlr4 runtime for any language based on JavaScript. That can be addressed with package description.
  • Versioning. The NPM repository uses using SemVer for versioning. Semver conventions means that our version numbers may get out-of-sync with the general ANTLR version, we should decide if we want to try to keep them close (e.g. match major & minor version numbers), or start the package at 1.0 (per NPM recommendation.)
  • debugging support: inclusion of source map files? See below.

NPM naming conventions are lowercase, with hyphen as separators. At a minimum, I think we need to publish two packages:

package-name Description Typical use
antlr4ts ANTLR4 runtime for TypeScript npm install --save antlr4ts
antlr4ts-cli ANTLR4 tool for TypeScript npm install -g antlr4ts-cli for system-wide install, and/or npm install --save-dev antlr4ts-cli for a specific project.

antlr4ts

Note: It seems a bit unclear if we should include the .ts and .js.map files as part of the antlr4ts runtime package. Basarat's has a sample npm module which includes the .ts files, but not the .js.map files, which seems illogical. I've posted basarat/ts-npm-module#6 to see if he has some specific logic for this.

antlr4ts-cli

Obviously, the antlr4ts-cli project will have a Java runtime dependency, and include the .jar file for our version of the tool. We may want to have it check the Java runtime is present and up-to-snuff when installed.

Even though the package will have a suffix, the command name won't need to include it. Do we want to make the antlr4ts command run the TypeScript compiler on the generated files? (I think the answer is yes. We should set it up so that the global install will respect a project-local installed version (if present) when selecting which .jar to run.

Other notes

  • The npm command-line tool can manage git tags corresponding to published versions.
  • Is it desirable to publish from the appveyor build products?

@BurtHarris
Copy link
Collaborator Author

Most of this is now ready, and w/ #244 I'm bumping the version number (manually) to 0.4.0. Plz review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants