search

bencodezen / vue-enterprise-boilerplate

An ever-evolving, very opinionated architecture and dev environment for new Vue SPA projects using Vue CLI.
7.78k stars 1.32k forks source link

Compatibility with latest vue-cli #46

Closed stuta closed 6 years ago

stuta commented 6 years ago 
yarn upgrade-interactive --latest
yarn dev

Invalid options in vue.config.js: child "css" fails because ["modules" is not allowed]
stuta commented 6 years ago

I'm not a git expert. How I can update latest changes from this boilerplate and still use my own git where my own changes (+ this boilerplate) go?

batFormat commented 6 years ago

I encountered the same problem when updating dependencies

chrisvfritz commented 6 years ago

@stuta When upgrading betas, breakages are unfortunately likely to happen, which is why I lock to specific versions in package.json. If you change the version ranges in package.json, your code will no longer be guaranteed to work. The boilerplate has now been updated to use Vue CLI 3.0.0-beta.10 and you can see the changes I made in this commit.

To get a complete list of changes that have been made since you cloned, you can use the GitHub compare link in your local README, generated by the _start.js script. If you notice any changes you'd like to have in your local setup, you can update your local files accordingly. Let me know if that makes sense. 🙂

stuta commented 6 years ago

Yes, it makes sense. I understand that in production boilerplate update can be dangerous, but I'm starting a new project and I want to have latest Vue features.

Is there any way to automate this boilerplate update? Like yarn update boilerplate.

chrisvfritz commented 6 years ago

Everything that can be automated I try to move into Vue CLI directly. For the rest, it would unfortunately be impossible to know what I can safely override without potentially breaking or even overwriting what you've already added. The compare URL I add to the README is the compromise I've come up with to show you everything that has changed, but allow you to explicitly choose what you want to bring into your local project.

stuta commented 6 years ago

I was hoping that some way updates could be automated. I have to learn more, I'll get back if I have some ideas.

stuta commented 6 years ago 
yarn upgrade-interactive --latest
yarn dev

vue-loader was used without the corresponding plugin. Make sure to include VueLoaderPlugin in your webpack config.
stuta commented 6 years ago

Maybe something like this: https://github.com/GarageGames/Torque2D/wiki/Cloning-the-repo-and-working-with-Git

Idea is to fetch/pull latest changes from this repo and merge to my own branch in my own repo. This way we can let the git to do the hard work. But like I said, I'm not a git expert.

chrisvfritz commented 6 years ago

@stuta The version ranges in package.json are specified for a reason. If you force upgrade all packages to their latest version, even when it's outside the specified range, you can expect things to break. If you want to upgrade some packages to solve a specific problem, you'll want to look at the changelog for each package and update them one at a time.

Regarding automation, this just isn't something a tool can solve. You'll have to actually look at the code and decide what you'd like to bring in, or leave the code as it is because it already works.

stuta commented 6 years ago

I understand versions in package.json, especially here because this is 'enterprise' -boilerplate. We just happened to be in point of starting and wanted to start with webpack 4.

Regarding automation, I think git merge is the perfect tool for that. At least we use it all the time to merge stable version changes to development version. In this case vue-enterprise-boilerplate is the stable version and our version is development version. But I can live easily with 'You diverged from the boilerplate' -link. I just don't like manual copy-paste in the long run.

chrisvfritz commented 6 years ago

Regarding automation, I think git merge is the perfect tool for that. At least we use it all the time to merge stable version changes to development version. In this case vue-enterprise-boilerplate is the stable version and our version is development version.

@stuta It's not quite that simple, unfortunately. Unlike the scenario with dev and stable branches, there is no point at which your local project is meant to be merged back into this project. In fact, your local should diverge quite drastically as you build your app and adapt the config to suit your specific domain and team.

The goal of this project is to serve as a great starting point for a new project and a great reference to improve existing projects. However, it does not have a goal of providing an upgrade path for existing projects based on it - that's what Vue CLI 3 and its plugins are for.

That means there's no guarantee (or goal) of backward-compatibility. I want to keep this project up-to-date to reflect the setup I would (and do) use to start a new enterprise project, even if that requires huge changes to the fundamental architecture and tooling of the app. Even for my own client projects, I'm not updating each of them to reflect every change I make here.

For example, once starting a project, a user might:

After that, using git merge to pull in changes from this boilerplate are likely to add a lot of unwanted files/code (including subtle breaking changes) and massive conflicts, forcing you to go over all of it manually in the end.

If you still want to use git merge, but want to save yourself some headache, I'd recommend:

# Merge in changes without committing
git merge --no-commit --no-ff vue-enterprise-boilerplate/master

# Unstage all changes
git reset HEAD

# Start picking and choosing the changes that you want
git add --interactive

# Commit
git commit -m "pull in updates from vue-enterprise-boilerplate"

But even that will take longer than skimming the diff in the compare URL, then selectively copying over anything you might want.

stuta commented 6 years ago

Thanks for the git info, I will try those things. For now the compare URL is good.

I did merge changes manually using compare URL so my system is on par with boilerplate. But there is a small problem now, how do I change the compare URL to point to latest boilerplate master?

chrisvfritz commented 6 years ago

After pulling in all the changes you want, you can manually update the compare URL to use the SHA of the current most recent commit, replacing the SHA of the most recent commit when you cloned.

stuta commented 6 years ago

This is exactly what I was looking for. It works wonderfully.

Configure: configuring-a-remote-for-a-fork. Sync: sync changes you make in a fork.