-
-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clean install: HMR broken! #16
Comments
I've added a commit to the Create a new vue project as normal and then install and invoke like this to test this out: Once we have some validation HMR appears to be working, i'll push to |
The command to test had incorrect URL to git/branch, and its For anyone using this patch for the issue, if run into this: |
Amazing! It worked on the clean project. Another issue - possibly related - after installing the plugin, HMR is also broken on Symptoms:
& Page reload +RangeError on update:
I've found the workaround, which is to create project, install plugin & then:
Perhaps it's a simple fix, by ensuring the plugin doesn't add a separate |
Glad you got it mostly working. Sorry about giving you the incorrect link for the install. That's what get for trying to do it from my phone. I'm not sure about why webpack would be doing that. We have webpack as a dev dependency of the plugin so it shouldn't be installing a second copy of it as far as I know. Can you show me what you have globally installed: |
Global npm list:
Though I think what's relevant is npm list inside project:
|
Actually the workaround is not just reinstalling @vue/cli-service, but also webpack:
Notice webpack uses webpack**@4.28.4** - important to fix the issue. Without the version specified, the issue persists. During the installation, plugin adds following to Which causes it to install @4.32.2. Before adding the plugin, there is no direct dependency in package.json (it's installed in vue/cli-service as a dep, using the @4.28.4) After re-installing webpack & cli-service(sequence is important),
Notice the deduped |
I was able to reproduce the issue and solve it via your method. Thanks for troubleshooting it and giving me a direction for a fix. However, probably not the best thing to have everyone need to do for each new project. I've updated I think the underlying issue may be a Long term what this means is that this project will need to try and make sure the version of |
Perhaps there might be a way to set the version, by first running a hook (pre-install or something?) to detect current vue-cli's
Will test on #dev and let you know |
For some reason
That was when it ran from Vue UI. Not sure what caused it. First running serve:web was fine, but if ran serve:ios first, then this was triggered. Tried adding UI works too after refresh. No clues so far. |
Another thing - on the Perhaps moving the dep inside might help? |
I cannot reproduce the UI issue. However, I do know that with the UI, it will sometimes mess with the parameters being passed to the CLI behind the scenes. What you can do is tell the UI to not set the To do this:
All that said, I just pushed a commit to |
Same error keeps (UI bug) Seems it's running Here's a full log:
|
But the HMR seems fixed(web)! no double message [HMR] and modules seem to reload correctly! Hopefully last thing: eslint is angry on It's fine when @ is used, but `Unable to resolve path to module (import/no-unresolved.
|
The webpackConfig error above is being generated from here: vue-cli-plugin-nativescript-vue/index.js Line 116 in 1fbbfe4
What that tells me is that for some reason for you, the UI is interfering with the I had just uncommented that error check out in the However, the better long term solution is to try and figure out why it's causing you an issue. Let me know if you are willing to continue to troubleshoot why it's failing that error check and I'll give you some guidance on what you can do to help me troubleshoot without you having to create a new project and install the |
Sure, I can help figure this out. Let me know what the flow is - and yes, I have like 8 repos already from fresh installs ;) The issue didn’t happen every time - it seems to have been intermittent, but latest project was giving the error every time. It’s weird, as whenever it happened from UI-launched serve:web, if I tried running from CLI, no error and works every time. I’ve already tried enabling the option “Override hard coded arguments” in the UI. Yet I got a feeling as if that didn’t quite change anything. Changing I don’t think disabling the check is the best option - let’s not do that for the time being. If it’s being tripped - then seems the env is not passed around where it should be & so it might end up silently breaking another part of the deploy/flow. |
Do you have any suggestion on the ~ imports? See comment above: #16 (comment) |
ok....i'm going to make one more commit to after this commit, we can continue further troubleshooting by directly editing the plugin inside of As for the So, if you want to change all of the |
I know the ~ & @ should resolve to the same paths, but after looking into vue’s webpack config(under To see it, do a search in all files under Your guess about global ESLint being in the way could be going the right way, but I’ve tested switching between global & local (in Atom’s linter-eslint settings menu), and it gave same results. I did previously have an issue with it using global(without me realising), and the global eslint was outdated, causing random rule not defined etc. Now that seems to be solved. I could just replace all the ~ to @‘s, but don’t understand what’s causing the behaviour. This also happens both in Atom & VScode, so not editor/linter specific. On previous versions of the package(e.g. non-dev branch) adding:
Was enough to fix this. Doesn’t work now however, and also I’ve tried through adding to vue.config.js:
Ah man, can’t wait to have no issues on tooling.. running behind schedule with all these getting in the way 😬 I’ll pull your latest commit in the morning and give it a spin, thanks for looking into this! |
Ok, so it gave the error straight after install in clean project. Log in the gist: The env is first populated / normal in
edit: added a log from a similar error, but different checks triggered, if running with "override hard coded args"=true & env mode = development (set in UI ->parameters) 2nd edit after that, I ran
Checked on git, no changes apart from webpack.config.js, as I ran setup-webpack-config before doing all of the above. Even reverting/discarding webpack.config.js changes, it still runs without errors in UI now. Seems as if the command from UI doesn't run some kind of Thinking of running So diff gave nothing:
|
diff on full project gave only node_modules/.cache changed. So... the cache files are to blame. When running a clean project, the cache directory is only containing This is the state both after installing the plugin, as well as after running I then ran the project from command line - it ran successfully, at which point a diff of that project & it's cloned directory pre-successful-run, gave the following diff:
I had then verified, that deleting those cache files, has made the UI-run produce the error again. Removing any single directory in Also, I've verified this is not related to a global eslint installation - as I removed eslint along with all eslint-related packages globally |
Well...I just have not been able to reproduce this. I've tried on almost a dozen different test projects while using different versions of node, npm, nativescript, etc. I've tried deleting the folders in i don't know why it's doing what it's doing for you. However, because you do have a workaround where you can run it from the cli first, i'm going to let this issue sit open and we'll see if others end up having the same sort of issues as you. I'm going to take the additional logging back out of the EDIT: Taking the project to 0.1.0 |
Sure, lets do that. Food for thought: vuejs/vue-cli#1128 (comment) seems related, though no fix |
I did fix an I found that my Not sure if that will help or not with the initial UI serve or not, but you can try it out and see. |
Nope, didn't change anything. I've also just tried by copying Also tried adding this to
No luck either. |
Fixed in #24 - This takes on the assumption that |
@vpiskunov Any word on when this fix will be implemented? Definitely not trying to rush you, but we're looking at using this plugin for a project at work and we're bumping into this issue, so I just want to see if this is something we can use at this time or in the near future. Again, I'm sure you have other things to do, so if this is still going to take a bit or the solution isn't quite there, absolutely no worries! |
I've just released 0.2.0 of the plugin to npm. This includes NS 6.1.0 and NS-Vue 2.4.0. It also includes PR #24 that addressed the platform setting. Try it again and let me know if this addresses things. |
So...my mistake. I somehow inadvertently didn't get PR 24 into 0.2.0. Issue with my local copy of the plugin. I've added it back and have released 0.2.1 |
Hey @alexandersix If that works, you only have to do it from terminal sometimes, when getting the error, as after that it works from UI too. Let me know |
When creating a new project, using Vue CLI 3, both in CLI and UI mode.
Then adding
vue-cli-plugin-nativescript-vue
.HMR simply keeps reloading the whole app & relaunching.
When adding
useLegacyWorkflow: false
innsconfig.json
it then loads changes but those don’t get applied until force-quitting the app on device & opening again?Tried running:
tns run ios
using default webpacknpm run debug:ios
npm run serve:ios
npm run setup-webpack-config && tns run ios --hmr --env.development
This does not happen when setting up a new project using
nativescript-vue/vue-cli-template
, in which case HMR is perfect.The text was updated successfully, but these errors were encountered: