Skip to content
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

Merged
merged 89 commits into from
Jan 16, 2021

Conversation

non25
Copy link
Contributor

@non25 non25 commented Jan 15, 2021

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 and test/loader.spec.js changes.

rixo and others added 30 commits July 29, 2019 01:37
This was referenced Jan 15, 2021
@@ -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`);
Copy link
Member

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)

@benmccann
Copy link
Member

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

@non25
Copy link
Contributor Author

non25 commented Jan 15, 2021

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?
For me the only relevant part is:

            // 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 ?

index.js Outdated Show resolved Hide resolved
@@ -20,30 +20,6 @@ const pluginOptions = {
markup: true
};

function makeHot(id, code, hotOptions) {
Copy link
Member

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?

Copy link
Contributor Author

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

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.

Copy link
Member

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:

if (!pluginOptions[option]) compileOptions[option] = options[option];

Since none of these are compiler options we should probably remove them all

Copy link
Contributor Author

@non25 non25 Jan 16, 2021

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. 😕

Copy link
Member

@benmccann benmccann Jan 16, 2021

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

Copy link
Contributor Author

@non25 non25 Jan 16, 2021

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.

Copy link
Member

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

Copy link
Contributor Author

@non25 non25 Jan 16, 2021

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. 😄

@benmccann
Copy link
Member

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

@non25
Copy link
Contributor Author

non25 commented Jan 16, 2021

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

I was pulling code from https://github.com/rixo/svelte-loader-hot and was confident that you pointing at svelte-loader-hot too. The same info was in my first commit message

Merge branch 'master' of svelte-loader-hot into merge-rixo-hmr

That could explain my confusion on merging README.md part.

I did it that way because I know that svelte-loader-hot works as I'm using it daily.

@benmccann
Copy link
Member

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

@non25
Copy link
Contributor Author

non25 commented Jan 16, 2021

What did you compare, can you send me a link? I compared this:
non25/svelte-loader@merge-rixo-hmr...rixo:svelte-hmr
Can't say that they are almost the same. 🤔

It looks like hotReload in plugin options describes that this option is possible to pass at all. Not that hotReload is turned on by default.

I've just tested it by omitting hotReload from webpack.config.js. It is not enabled by default.

@benmccann
Copy link
Member

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.

@non25
Copy link
Contributor Author

non25 commented Jan 16, 2021

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.

@non25
Copy link
Contributor Author

non25 commented Jan 16, 2021

I have finally understood what pluginOptions do. They prevent passing described options from options object to the compiler.

@benmccann benmccann merged commit 7b81c00 into sveltejs:master Jan 16, 2021
@non25 non25 deleted the merge-rixo-hmr branch January 16, 2021 14:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants