Invalid updating flow about sharec HOT 15 CLOSED

Thank you for issue! I think this problem directly relates to #46. I will fix both problems as soon as it possible.

from sharec.

I checked the latest sharec and it repeats the problem.

You can repeat the problem by cloning Nano ID, switching to this commit and then call yarn upgrade-interactive --latest with config update.

from sharec.

So, I have switched to this commit and tried to update configuration:

 "scripts": {
-   "api": "documentation build *.js {async,non-secure}/*.js -f md -o api.md",
+   "api": "documentation build *.js -f md -o api.md",
    "spell": "yarn api && yaspeller-ci *.md",
    "clean": "rimraf api.md coverage/",
    "lint": "eslint-ci . --ignore-pattern 'node_modules' --ignore-pattern 'test/demo/build'",
-   "test": "jest --coverage && yarn lint && yarn spell",
+   "test": "jest --coverage && eslint-ci . && size-limit && yarn spell",
    "start": "parcel serve test/demo/index.html -d test/demo/build --open"
  }

Is it ok? I can advice you to use lastest release after publishing.
If it problem will be figure in again – feel free to reopen this issue.

from sharec.

Does still sharec override my commands during the update? My point is that during config updating if sharec see that package.json already have the command with a different value, sharec should not change it.

Here is an example:

Sharec config version 1

"scripts": {
  "a": 1,
  "b": 1
}

Sharec config version 2

"scripts": {
  "a": 2,
  "b": 2
}

package.json:

"scripts": {
  "a": 10,
  "b": 1
}

During the update from 1 to 2, the result should be:

"scripts": {
  "a": 10,
- "b": 1
+ "b": 2
}

from sharec.

@ai ah, I finally got it.
Yes, there is a big problem, because before update sharec removes previous installed configuration and applying next one.
So, I need some time to research possible ways to solve this problem.

from sharec.

I think, we should backup previous applied configuration to the abstract lock-file because during update installing we have not access to previously installed configuration. I think it is not very difficult but it can really solve your problem.

from sharec.

think, we should backup previous applied configuration to the abstract lock-file

Good idea, we can do it in node_modules/.cache/sharec/CONFIG_NAME/VERSION

from sharec.

I think better idea to store it in the project root, because in your case – we will lost this feature on repository level (node_modules commonly ignored).
And if we have look on the new package managers – node_modules will be rudimentary thing in the near future, imo.

from sharec.

Correct me if I'm wrong :)

from sharec.

We are creating a tool to deal with less configs. Adding new config will be very bad for promotion.

In my experience JS developers against any new files in the root (I agree with them, extra file moves README below in the page and reduce promotion potential of my tools).

from sharec.

Ok, I see.
It will be just restriction and users should accept it before use.

from sharec.

It will drastically reduce benefits of the tool. A lot of users will refuse using library because of the extra file in the root.

Another way is to download previous version from mom directly.

from sharec.

Yes, I absolutely agree with you!👌

from sharec.

@ai I have a big progress here. Left next things before new version release:

• - Update redesign
• - Remove command redesign
• - Cache for all strategies, like eslint or babel

from sharec.

@ai finally – I have done that issue.
Eslint and other strategies were not affected in the last release but you can check issue with scripts.
I will make issues for other strategies.

from sharec.