-
Notifications
You must be signed in to change notification settings - Fork 72
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
Replace broken Svelte 2 HMR with the one from rixo #156
Conversation
update native support
Fix minor typo
test/loader.spec.js
Outdated
@@ -369,7 +369,7 @@ describe('loader', () => { | |||
function(err, code, map) { | |||
expect(err).not.to.exist; | |||
|
|||
expect(code).to.contain(require.resolve('../lib/hot-api.js').replace(/[/\\]/g, '/')); | |||
expect(code).to.contain(`lib/hot-api.js`); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use single quotes instead of backticks (if we apply svelte's linting to this repo at some point in the future that will be enforced. doing it now will make it easier to possibly setup)
Are you pulling the code from https://github.com/rixo/svelte-loader/tree/svelte-hmr ? At the very least, this PR doesn't appear to have the README changes that are there |
What do you mean by that? That we should pull changes to the readme? // NOTE Svelte's dev mode MUST be enabled for HMR to work
// -- in a real config, you'd probably set it to false for prod build,
// based on a env variable or so
dev: true,
// NOTE emitCss: true is currently not supported with HMR
emitCss: false,
// Enable HMR
hotReload: true, // Default: false
// Extra HMR options
hotOptions: {
// Prevent preserving local component state
noPreserveState: false,
// If this string appears anywhere in your component's code, then local
// state won't be preserved, even when noPreserveState is false
noPreserveStateKey: '@!hmr',
// Prevent doing a full reload on next HMR update after fatal error
noReload: false,
// Try to recover after runtime errors in component init
optimistic: false,
// --- Advanced ---
// Prevent adding an HMR accept handler to components with
// accessors option to true, or to components with named exports
// (from <script context="module">). This have the effect of
// recreating the consumer of those components, instead of the
// component themselves, on HMR updates. This might be needed to
// reflect changes to accessors / named exports in the parents,
// depending on how you use them.
acceptAccessors: true,
acceptNamedExports: true,
}
}
}
} Can we discuss code first ? |
@@ -20,30 +20,6 @@ const pluginOptions = { | |||
markup: true | |||
}; | |||
|
|||
function makeHot(id, code, hotOptions) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed that @rixo's branch does not have the below options specified in pluginOptions
externalDependencies: true,
hotReload: true,
hotOptions: true,
shared: true,
I think shared
does not exist and perhaps we don't want to enable the others by default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where did you get this from?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The svelte-hmr
branch: https://github.com/rixo/svelte-loader/tree/svelte-hmr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should only disable hotReload
by default and remove shared
. The other two doesn't do anything in true/false
manner.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like the only thing it's used for is to determine if it's a compiler option:
Line 81 in 0f1c49b
if (!pluginOptions[option]) compileOptions[option] = options[option]; |
Since none of these are compiler options we should probably remove them all
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is better to avoid making changes that are out of the scope of this PR.
Code could be improved, but in the other PR.
This place is hard to spot new comments on. 😕
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to clarify, when I said "all" I meant the four options I originally suggested removing: externalDependencies
, hotReload
, hotOptions
, shared
There shouldn't be any reason to pass those to the compiler since none of those four are valid compiler options: https://svelte.dev/docs#svelte_compile
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to clarify, when I said "all" I meant the four options I originally suggested removing:
externalDependencies
,hotReload
,hotOptions
,shared
Doing this breaks tests and compilation. These options are PREVENTED from going to the compiler due to the pluginOptions
object and code above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see. Sorry I had that backwards. It's a bit confusingly written. In rollup-plugin-svelte
we moved them to be under compilerOptions
. We should probably do that here too, but that can be a separate change. Just removing shared
and leaving the rest as-is would make sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is done.
Yeah, that made me scratch my head for several minutes too. 😄
I was suggesting you replace the README with the version at https://github.com/rixo/svelte-loader/blob/svelte-hmr/README.md. I would just copy the whole thing over. The code generally looks fine to me |
I was pulling code from https://github.com/rixo/svelte-loader-hot and was confident that you pointing at
That could explain my confusion on merging I did it that way because I know that |
https://github.com/rixo/svelte-loader/tree/svelte-hmr is almost the same as your PR. I compared them. The only things to update are the options I mentioned and the README. If you update those then we can probably merge this |
What did you compare, can you send me a link? I compared this: It looks like I've just tested it by omitting |
You can't compare on the web interface for some reason. I'm not sure why it's screwed up. I had to pull down both repos locally and switch to the relevant branches to compare them. |
Interesting, didn't know that. Just cloned both repos, compared and yes, they almost the same. Deleting options breaks tests. I would leave them for now and concentrate on releasing working HMR and working Webpack 5. We can refactor later. |
I have finally understood what |
I've moved some code around to drop Svelte 2 hmr support, removed unneccessary code to make diffs smaller and easier to understand.
Tested on both webpack 4 and 5, it works.
I think it is fair to look only for
index.js
,package.json
andtest/loader.spec.js
changes.