Closed fsmaia closed 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?
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
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?
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?
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.
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.
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.