Exclude unnecessary files from distribution

sindresorhus / atom-editorconfig

Helps developers maintain consistent coding styles between different editors

https://atom.io/packages/editorconfig

MIT License

812 stars 80 forks source link

Exclude unnecessary files from distribution #153

Closed Alhadis closed 7 years ago

Alhadis commented 7 years ago

Follow-up of #152, which I submitted before learning there's a more efficient way to exclude files in package tarballs (thanks @gorriecoe).

This PR knocks ~1.6 MBs off the package's total size, ensuring updates are downloaded to users quicker.

sindresorhus commented 7 years ago

This should use the files property in package.json instead.

https://docs.npmjs.com/files/package.json#files

Alhadis commented 7 years ago

That won't work. See for yourself:

apm install aobakle

If you check the package directory after installing, you'll notice nah.js sitting there among the downloaded files, despite the files array specifying only yeah.js.

Reason: Atom's package manager isn't NPM, despite being a heavily-mutated version of it.

florianb commented 7 years ago

@Alhadis -- this is a great approach. Thank you very much. I didn't even think about this kind of optimization. Lesson learned.

It seems the build fails now for the fall-back-selector i added to fix the broken wrap-guide during the shadow-transition process. I will dig into that at monday (i guess).

Alhadis commented 7 years ago

I noticed that. My approach would be to modify the existing wrap-guide element dynamically, rather than synthesise a replacement.

Benefits:

Users who've hidden the wrap-guide (either with CSS or by disabling the wrap-guide package) won't see the guide appear out of nowhere (something which caught me by surprise)
Users who've styled the appearance of their editor's wrap-guide will have their customisations preserved
No deprecation warnings caused by deprecated selectors, since you'll simply be riding atop a core-package

Failing that, you could try looking into Atom's decorations API and seeing if that would be useful.

Alhadis commented 7 years ago

@sindresorhus Please confirm when you've acknowledged my explanation so I know when to annihilate that abortion of digital runoff. =)

sindresorhus commented 7 years ago

@Alhadis Ah, I didn't realize. That's definitely annoying. From the apm readme:

apm bundles npm with it and spawns npm processes to install Atom packages. Therefore you can think of apm as a simple npm wrapper that builds on top of the many strengths of npm

Would you mind opening an issue on apm about supporting the files property in package.json?

Alhadis commented 7 years ago

No need, it's a known limitation.

The differences in implementation are probably infrastructure-related, judging by the way apm peels tarballs from GitHub instead of its own servers (which I believe is different to npm's treatment of packaging modules).

sindresorhus commented 7 years ago

Alright. Thanks for clarifying. 👍

Alhadis commented 7 years ago

@gorriecoe Just a heads up that this might be a fluke, and relying on export-ignore mightn't stay the same forever. I've brought it to the Atom team's attention; the fact .gitattributes hasn't been mentioned anywhere as a solution (by either staff or users) is pushing a splinter of doubt in the back of my head.

As for the .editorconfig file, well, it would still make sense for this package to include a reference copy of its own format... and users can still open a package's contents in Atom by clicking the View code button in the settings-view. Besides, these files aren't adding much weight when gzipped... the issue is with binary files, which don't compress well.