alephjs/aleph.js

`aleph start` fails to start the app

shreyashsaitwal opened this issue · 6 comments

Description

Running aleph start fails with the following output:

$ aleph start -L debug

TIMING load config in 10ms
TIMING init env in 7ms
TIMING apply plugins in 0ms
TIMING init react framework in 51ms
DEBUG load '/pages/index.js' • 2.3KB
DEBUG load '/pages/index.js' • 2.3KB
DEBUG load '/pages/index.js' • 2.3KB
 > error: Could not read from file: D:\Projects\deno\aleph-test\D:\Projects\deno\aleph-test\.aleph\production\vendor.bundle.entry.js

error: Uncaught (in promise) Error: Build failed with 1 error:
error: Could not read from file: D:\Projects\deno\aleph-test\D:\Projects\deno\aleph-test\.aleph\production\vendor.bundle.entry.js
  let error = new Error(`${text}${summary}`);
              ^
    at failureErrorWithLog (https://deno.land/x/esbuild@v0.13.2/mod.js:1439:15)
    at https://deno.land/x/esbuild@v0.13.2/mod.js:1097:28
    at runOnEndCallbacks (https://deno.land/x/esbuild@v0.13.2/mod.js:885:63)
    at buildResponseToResult (https://deno.land/x/esbuild@v0.13.2/mod.js:1095:7)
    at https://deno.land/x/esbuild@v0.13.2/mod.js:1204:14
    at https://deno.land/x/esbuild@v0.13.2/mod.js:573:9
    at handleIncomingPacket (https://deno.land/x/esbuild@v0.13.2/mod.js:670:9)
    at readFromStdout (https://deno.land/x/esbuild@v0.13.2/mod.js:540:7)
    at https://deno.land/x/esbuild@v0.13.2/mod.js:1709:11

How to reproduce?

To reproduce the issue, simply create a new Aleph app using aleph init and try to start it using aleph start.

Other details

OS: Windows 11 (Build: 22000.168)
Deno version: 1.14.3
Aleph version: v0.3.0-beta.19

Do I need to provide any other info to help triage this issue?

same issue here, can't start a freshly init aleph app and the debug log shows that duplication in the path to the project directory.

sno2 commented

I have pinpointed the error to ~/bundler/mod.ts where we use ESBuild when it is trying to build the vendor files in ~/bundler/mod.ts. It is odd, though, because the input paths are the following when I logged them out in my valid project:

await esbuild({
	entryPoints: "C:\projects\deno\aleph.js\pass\.aleph\production\vendor.bundle.entry.js",
	outfile: "C:\projects\deno\aleph.js\pass\.aleph\production\vendor.bundle.93515650.js",
	platform: 'browser',
	format: 'iife',
	target: [
		String(build.target),
		...Object.keys(build.browsers).map(name => `${name}${build.browsers[name as BrowserName]}`)
	],
	bundle: true,
	minify: true,
	treeShaking: true,
	sourcemap: false,
	plugins: [denoPlugin],
})

Also, here is my error message:

 > error: Could not read from file: C:\projects\deno\aleph.js\pass\C:\projects\deno\aleph.js\pass\.aleph\production\vendor.bundle.entry.js

Therefore, it seems esbuild-deno is appending paths incorrectly on Windows as it works on WSL for me. Furthermore, you must delete the .aleph folder before running on Windows as it will do a false-positive because the only thing failing is the vendor generation which will pass if you built with Linux/Mac OS the first time.

same issue, i am on windows, the error shows that the directory is duplicated:

error: Could not read from file: C:\Users\username\Desktop\Projects\myapp\C:\Users\username\Desktop\Projects\myapp\.aleph\production\vendor.bundle.entry.js

this is a totally fresh install.

For anyone else stumbling across this issue, the problem lies with the plugins defined in ~/bundler/esbuild.ts which are attached to the esbuild instance imported into ~/bundler/mod.ts.

In the plugins they make the assumption that a path must lead with / to be absolute, which is accurate on pretty much every non-Windows platform. When detected as not absolute, the path is passed to join where it is simply concatenated and normalized (here and here).

// ensure the `path` is an absolute path
if (!path.startsWith('/')) {
  return { path: join(args.resolveDir, path) }
}

Instead of using join, which concatenates the pieces together, swapping it out for resolve instead correctly handles the coercion to an absolute path.

import { resolve } from 'https://deno.land/std@0.106.0/path/mod.ts' // instead of `join`

// DO THIS FOR BOTH 'css-resolver' and 'deno-resolve-loader'
// ensure the `path` is an absolute path
if (!path.startsWith('/')) {
  return { path: resolve(args.resolveDir, path) }
}

return { path };

Personally, I ended up letting the path module handle the coercion entirely by removing the condition:

import { resolve } from 'https://deno.land/std@0.106.0/path/mod.ts' // instead of `join`

// DO THIS FOR BOTH 'css-resolver' and 'deno-resolve-loader'
// ensure the `path` is an absolute path
return { path: resolve(args.resolveDir, path) }

For anyone else stumbling across this issue, the problem lies with the plugins defined in ~/bundler/esbuild.ts which are attached to the esbuild instance imported into ~/bundler/mod.ts.

In the plugins they make the assumption that a path must lead with / to be absolute, which is accurate on pretty much every non-Windows platform. When detected as not absolute, the path is passed to join where it is simply concatenated and normalized (here and here).

// ensure the `path` is an absolute path
if (!path.startsWith('/')) {
  return { path: join(args.resolveDir, path) }
}

Instead of using join, which concatenates the pieces together, swapping it out for resolve instead correctly handles the coercion to an absolute path.

import { resolve } from 'https://deno.land/std@0.106.0/path/mod.ts' // instead of `join`

// DO THIS FOR BOTH 'css-resolver' and 'deno-resolve-loader'
// ensure the `path` is an absolute path
if (!path.startsWith('/')) {
  return { path: resolve(args.resolveDir, path) }
}

return { path };

Personally, I ended up letting the path module handle the coercion entirely by removing the condition:

import { resolve } from 'https://deno.land/std@0.106.0/path/mod.ts' // instead of `join`

// DO THIS FOR BOTH 'css-resolver' and 'deno-resolve-loader'
// ensure the `path` is an absolute path
return { path: resolve(args.resolveDir, path) }

Hey, @samthecodingman , how do I change that in my project? I'm facing this issue too!