-
Notifications
You must be signed in to change notification settings - Fork 298
Use release archives instead of release tags #498
Comments
This is good feedback - thank you. These are definitely edge cases, as the current deployment strategy works for the majority of the thousands of packages on atom.io, but as we want to embrace more comprehensive IDE features helping people keep their repos clean would be helpful. As you note, backwards-compatibility is important. Another concern of mine is that releases be consistent - that is to say, we want to avoid someone shipping a release and then changing the downloaded archive later - version 1.1 (or whatever) should always be the exact same code. This probably won't make it onto our roadmap in the very near future, but I think it's interesting to have a discussion here about what we can do to address the various pain points - the one most interesting to me is transpilation - are there other ways this could work to prevent check-in of build products without adding a second place to put products for download? e.g. a transpilation step on the server side for the most popular targets like typescript, etc? |
I think Atom should generalize its involvement in transpilers rather than have first class support for a few (looking at you, CoffeeScript and Babel), and enable developers to set up easily with whatever transpiler they choose. VSCode has generalized transpilers/compilers by hooking them into the package's config and into VSCode's task runner for refresh/reload development. While all the transpiler examples talk about and show TypeScript, they demonstrate they are just shelling out to the TS Compiler, Ideally developers shouldn't have to commit transpiled code in order to release it, and they should be able to exclude the source files from the released package. An '.apmignore' file would accomplish the second part, like @steelbrain mentioned, and that is the direction that VSCode went with its '.vscodeignore'. Their Yeoman project generators are set up for TypeScript, but VSCode only runs JavaScript. The projects add |
That means that for now we need to check in our compiled sources (the lib directory). This may eventually fix: atom/apm#498
I recently learned it's possible to exclude resources from package distributions by using
This attribute relates to the
This seems to be a more logical approach than using an However, the fact this works based solely on a redirect to GitHub makes me hesitant to embrace it as a long-term solution. How likely is it that Atom's package repository will continue serving tarballs this way? Infrastructure changes are inevitable, and packages might one day be served using a strategy that doesn't involve a call to The existence of |
For myself, I have the opposite problem @Alhadis. There are files which I want excluded from git (because they are build artifacts, and so diffs etc aren't useful) but included in my atom plugin. .npmignore allows this because npm ignores the .gitignore file when it is present. |
Diffs can easily be suppressed using |
- Added git attribute to export-ignore build-time babelrc config More info: atom/apm#498 (comment) Closes AtomLinter#796
- Added git attribute to export-ignore build-time babelrc config More info: atom/apm#498 (comment) Closes AtomLinter#796
- Added git attribute to export-ignore build-time babelrc config More info: atom/apm#498 (comment) Closes #796
Unfortunately, Atom's package manager `apm` does not allow packaging of untracked files, which means that the compiled `.ez` archives from ElixirLS have to be committed. (See [issue #498](atom/apm#498))
Is this still considered an edge case? The JS ecosystem has changed since 2016, now almost everybody uses Babel, and Typescript is getting a lot of traction. It feels bad to have the transpiled JS in the repo just to include it in the package. |
Just to give some insights on modern package development, I would like to share my workflow, hoping that For my own package development, I'm following Microsoft's suggestion for VSCode to use bundling.
In practice, I'm using Webpack to create a bundle from all files in Ultimately, I think that if many package developers adopt bundling strategies, not only their packages will benefit, but Atom as a whole. Calling this feature request an edge-case is a bit short-sighted, don't you think? |
I made a solution to this. We can use build-commit:
|
@idleberg I think it is right, though for your case. For the record, if you are shipping a transpiled copy of all of your required modules or functions, and loading them from the transpiled output at runtime, then end-users don't need your Specifying a |
Summarizing what has been said earlier in the thread: some of these capabilities folks are asking for here are already available.
That leaves some room for improvement, so yeah, I agree being able to actually directly upload tarballs of Atom packages would be an improvement. I just thought it would be nice to restate that info simply and put it in one place, in case folks are in need of a workaround today. Solutions available today, in more detail
As @Alhadis mentioned, the same effect can be achieved by making a
As a compromise, you can update the built files only on every release, which can be automated if desired, like what @aminya proposed and already does for some of the Atom IDE packages.
If you are willing to commit every file in the monorepo, then monorepo is perfectly doable. (Which is a lot like how the While being able to upload tarballs would be an improvement in capabilities, there are some downsides as well:
|
The way releases are handled at the moment are great, but it has a lot of issues and problems
The problems
.apmignore
file in the repoThe solution
Create tar archive (or zip if you prefer) respecting ignore files and counting in files ignored by git repo from the the local version of the publisher. Add a release with the newly created tag and attach that archive with that release.
The release tag should be prefixed by package name, like
linter-ruby-v1.1
. The archive name attached to the release should be namedpackage-name.tgz
orpackage-name.zip
.When installing a package, check for the latest tag in APM database for that package, if the tag starts with
package-name
, try to find release for that tag and download the package file. Otherwise, just download the zip archive of commit as we do now. If we follow this pattern, we would be backward-compatible with the already released packages.I know the problems I mentioned above do not sound very important, but they are very annoying and very difficult to workaround.
For example @basarat, @blakeembrey and the rest of the
atom-typescript
team transpiles the typescript files and keeps them in their repo.@nmote @ssorallen @bolinfest and the rest of the nuclide team had to create a new github org
facebooknuclideapm
and create a repo in it for each package they wanted to publish.@david-driscoll and the rest of the
omnisharp-atom
team also has to transpile typescript files and keep them in the repo.@devoncarew and the rest of
dart-lang
team has to keep transpileddart
files in their repo.@steelbrain @Arcanemagus and the rest of
linter-eslint
team has to commit transpiled babel files into the repo, because we spawn a child process that requires our files and child processes don't support babel requiresThe text was updated successfully, but these errors were encountered: