Closed gonzofish closed 7 years ago
Note that erector-set
already provides an option to prevent overwriting files.
We'll need to track the template file changes from one version to another somehow.
For instance, if I move a file from src/main.file.ext
to src/main/file.ext
, maybe we should have a migration file that tracks this and can move files around accordingly. The file would just be a giant object:
module.exports = {
"src/main.file.ext": "src/main/file.ext"
// other changes
};
And we could move files around by looping through the object keys.
The other issue is that we might have a file, like package.json
which the user has most likely added files to, let's say they installed Angular 2 Material--we need a way of diffing those files so we can provide the latest and greatest changes.
We could look for unknown lines. Any lines we do not know about, we could keep and insert back into the replacement file. Maybe that's a naive implementation but it'd get the job done I think.
@litzebauer @rhutzel what do you guys think?
File diffing is going to be tough. package.json we'll know what information the generator previously put there so we can modify/remove that data and add things to it. It should be kind of easy since it's json. Is there a big need to move files around?
Yeah, probably don't need to move things around once it gets stable. I think package.json and some of the setup files are the big concerns. People won't change those for the most part so we can just let them decide if they want to replace the file, like Yeoman does.
With all the changes being made to this project, this feature is becoming more crucial. I'd be willing to take a first crack at it. I was thinking of creating a "upgrade" command which would do similar to the initial command but only overwrite files that we know the user shouldn't be manually changing like the webpack files, etc. I think another key file is package.json so maybe I could intelligently update that file. User would need to run the upgrade script whenever they upgrade the library. Thoughts? @gonzofish @rhutzel
Yeah I've got no problem with that. I just want to keep dependencies low because I don't want the package to be invasive and require a ton of downloads. On Sun, Feb 5, 2017 at 2:10 PM Jeremy Litzebauer notifications@github.com wrote:
With all the changes being made to this project, this feature is becoming more crucial. I'd be willing to take a first crack at it. I was thinking of creating a "upgrade" command which would do similar to the initial command but only overwrite files that we know the user shouldn't be manually changing like the webpack files, etc. I think another key file is package.json so maybe I could intelligently update that file. User would need to run the upgrade script whenever they upgrade the library. Thoughts?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gonzofish/angular-library-set/issues/4#issuecomment-277541259, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYjrqb7UaR_mkARD9wNY_8YH9zY1WvFks5rZh6QgaJpZM4Ly237 .
OK. I'll see if I can get to it sometime this week.
On Sun, Feb 5, 2017, 3:09 PM Matt Fehskens notifications@github.com wrote:
Yeah I've got no problem with that. I just want to keep dependencies low because I don't want the package to be invasive and require a ton of downloads. On Sun, Feb 5, 2017 at 2:10 PM Jeremy Litzebauer <notifications@github.com
wrote:
With all the changes being made to this project, this feature is becoming more crucial. I'd be willing to take a first crack at it. I was thinking of creating a "upgrade" command which would do similar to the initial command but only overwrite files that we know the user shouldn't be manually changing like the webpack files, etc. I think another key file is package.json so maybe I could intelligently update that file. User would need to run the upgrade script whenever they upgrade the library. Thoughts?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub < https://github.com/gonzofish/angular-library-set/issues/4#issuecomment-277541259 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AAYjrqb7UaR_mkARD9wNY_8YH9zY1WvFks5rZh6QgaJpZM4Ly237
.
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/gonzofish/angular-library-set/issues/4#issuecomment-277545366, or mute the thread https://github.com/notifications/unsubscribe-auth/ABLc6wJ1QowgFrEFwG1NliLH3if_7qy5ks5rZix3gaJpZM4Ly237 .
I also think it's beneficial to us, for now, to point our projects to the master of this instead of constantly releasing to NPM and waiting for our internal Nexus to update
Good point about pointing to master for now, given the frequency of changes.
I agree that files moving between directories is not something to be handled automatically. Things will stabilize and upgrades can include a brief README for the occasional manual step that needs to be taken.
Regarding diffs, I'm concerned about keeping upgrades manageable for the erector author and predictable for end user. I suggest we create a file if it doesn't already exist. If it already exists, rename the existing file to .orig, write the new file to .latest, and clearly flag it in the console that the two need to be diffed and merged before continuing.
This is needed for a couple reasons:
module.ts
file