amatiasq / vsc-sort-imports

Sort ES6 imports automatically.
ISC License
58 stars 24 forks source link

Fixes #18 #19

Closed fsmaia closed 6 years ago

fsmaia commented 6 years ago
amatiasq commented 6 years ago

Thanks, do you have a reference to what kind of options can we use?

This will be included in the next release, do you need this now?

fsmaia commented 6 years ago

These options are just passed to styles and can be used inside their implementation (that's why I didn't document). As example I developed a style that handles webpack aliases to sort imports: https://github.com/fsmaia/import-sort-style-module-alias

fsmaia commented 6 years ago

It would be nice to publish a new release, we started an effort in my current company to adopt sort-imports as part of good practices!

May I help somehow?

amatiasq commented 6 years ago

Version 5.1.0 released.

If you agree I'll add you as contributor so you can merge PRs yourself.

Publish is still made manually for now, I'm interested in your opinion: do you know semantic-release process? do you think this will improve how people contribute to this?

fsmaia commented 6 years ago

Thank you!

Sure, I can be a contributor, altough I believe current features are already enough to a state-of-art code organization in terms of imports :).

I didn't know semantic-release, it is definitely interesting, but it seems a little overkill to me. In my point of view, continuous integration/delivery involves a serious mindset change and it should be made by baby steps.

I also don't know about VSCode extensions publish workflow, but probably setting up a TravisCI with hooks/jobs on every change in master should be enough.

amatiasq commented 6 years ago

Yes, it's a little overkill, the thing is we'll have to update the version before we push to master or it will crash trying to deploy.

fsmaia commented 6 years ago

Hmm, that's nice! The way I'm used to in company and personal projects is to include npm version ${release_severity} right before build, and pushing the generated commit to git with tags after the last step (even after deploy steps).

By doing this I can be sure that artifacts are generated with correct version, and that this version is attached to package.json in master at the right time.

I think it is enough unless you need to prepare a release manually, choosing its severity (major/minor/patch) before deploying.