Revert "fix: hoist imports on top"

[Rich-Harris]

Reverts #13082

[changeset-bot]

⚠️ No Changeset found

Latest commit: 38b4053

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[Rich-Harris]

(I'm confused by the original issue, because imports are always hoisted by engines — there must be an unusual build process involved. Rather than making things more complex, the easiest thing to do to address that issue is probably just to revert #13048 as well, because it's not actually doing anything)

[paoloricciuti]

(I'm confused by the original issue, because imports are always hoisted by engines — there must be an unusual build process involved. Rather than making things more complex, the easiest thing to do to address that issue is probably just to revert #13048 as well, because it's not actually doing anything)

Uh i wonder if it's just a repl bug?

[paoloricciuti]

Mmm actually i can reproduce it with fresh pnpm create svelte. Curiously tho it's only in dev mode...and the problem is that in dev mode imports to node modules are actually converted to function calls by vite!

import { createHotContext as __vite__createHotContext } from "/@vite/client";import.meta.hot = __vite__createHotContext("/src/routes/+page.svelte");import "/node_modules/.vite/deps/svelte_internal_disclose-version.js?v=0ec42dc1";

$.mark_module_start();
_page[$.FILENAME] = "src/routes/+page.svelte";

export const b = _.cloneDeep({ f: '' });

import * as $ from "/node_modules/.vite/deps/svelte_internal_client.js?v=0ec42dc1";
import __vite__cjsImport2_lodash from "/node_modules/.vite/deps/lodash.js?v=0ec42dc1"; 
// this should be an import but it's a const
const _ = __vite__cjsImport2_lodash.__esModule ? __vite__cjsImport2_lodash.default : __vite__cjsImport2_lodash;

function _page($$anchor, $$props) {
	$.check_target(new.target);
	$.push($$props, false, _page);
	$.init();
	return $.pop({ ...$.legacy_api() });
}

if (import.meta.hot) {
	_page = $.hmr(_page, () => _page[$.HMR].source);

	import.meta.hot.acceptExports(["default"],(module) => {
		module.default[$.HMR].source = _page[$.HMR].source;
		$.set(_page[$.HMR].source, module.default[$.HMR].original);
	});
}

export default _page;

$.mark_module_end(_page);

[paoloricciuti]

Regarding the initial pr from @benmccann i think the purpose is to then use those variables in #13075 ...but tbf this almost seems like a vite bug so maybe we should revert #13082 and open an upstream bug in vite?

[Rich-Harris]

Ah, the const. Yes, this is a (fixable) bug in Vite — a little bit of an edge case but I'm surprised it hasn't come up previously.

We can work around it (and probably should, since we can't assume everyone will be on the the latest Vite version) but I think just undoing #13082 and #13048 is the most sensible thing to do in the near term — we can apply a workaround when we get round to the work that #13048 was designed to enable.