packem/packem

📦⚡ A precompiled JavaScript module bundler

packem's Issues

Cannot start Packem on MacOS (10.14.4)

OS: 10.14.4
Node: Tried 10.4.1 & 11.14.0

I followed installation instructions, but get following error:

Initializing bundle process...internal/modules/cjs/loader.js:731
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: dlopen(/Users/dveremchuk/.nodebrew/node/v10.4.1/lib/node_modules/packem/bin/index.node, 1): no suitable image found.  Did find:
	/Users/dveremchuk/.nodebrew/node/v10.4.1/lib/node_modules/packem/bin/index.node: unknown file type, first eight bytes: 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00
	/Users/dveremchuk/.nodebrew/node/v10.4.1/lib/node_modules/packem/bin/index.node: unknown file type, first eight bytes: 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:731:18)
    at Module.load (internal/modules/cjs/loader.js:612:32)
    at tryModuleLoad (internal/modules/cjs/loader.js:551:12)
    at Function.Module._load (internal/modules/cjs/loader.js:543:3)
    at Module.require (internal/modules/cjs/loader.js:650:17)
    at require (internal/modules/cjs/helpers.js:20:18)
    at Object.<anonymous> (/Users/dveremchuk/.nodebrew/node/v10.4.1/lib/node_modules/packem/src/core.js:22:33)
    at Module._compile (internal/modules/cjs/loader.js:702:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:713:10)
    at Module.load (internal/modules/cjs/loader.js:612:32)

LC source code?

Interesting idea. Any plan to publish the LC source code?
Also how this compare to Pax? https://github.com/nathan/pax

Thanks

Question: Where is the rust code?

Error running packem in OSX

after yarn global add packem
Error: dlopen(/Users/nevastap/.config/yarn/global/node_modules/packem/bin/index.node.. (not a mach-o file), '/usr/local/lib/index.node' (no such file), '/usr/lib/index.node' (no such file)

Error Running Packem on Windows 10

Hi, I've installed packem globally using:

npm install packem -g

I have Node version 12.14.0 (latest recommended build) and npm version 6.13.4 (also latest).

When I run packem in an example project I get the following error:

internal/modules/cjs/loader.js:1025
  return process.dlopen(module, path.toNamespacedPath(filename));
                 ^

Error: \\?\C:\Users\Louis\AppData\Roaming\npm\node_modules\packem\bin\index.node is not a valid Win32 application.
\\?\C:\Users\Louis\AppData\Roaming\npm\node_modules\packem\bin\index.node
    at Object.Module._extensions..node (internal/modules/cjs/loader.js:1025:18)
    at Module.load (internal/modules/cjs/loader.js:815:32)
    at Function.Module._load (internal/modules/cjs/loader.js:727:14)
    at Module.require (internal/modules/cjs/loader.js:852:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (C:\Users\Louis\AppData\Roaming\npm\node_modules\packem\src\ModuleGraph.js:1:60)
    at Module._compile (internal/modules/cjs/loader.js:959:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:995:10)
    at Module.load (internal/modules/cjs/loader.js:815:32)
    at Function.Module._load (internal/modules/cjs/loader.js:727:14)

I've tried uninstalling Packem, then reinstalling again, with the same result. Any help would be appreciated. Thank you.

Running packem deleted entire contents of directory

Just ran:

input: "foo.js"
output: "bundle.js"
format: "iife"

As a test inside a project, and it deleted the entire contents including the .git folder

Supporting typescript

Do you support typescript?
When I search word typescript on your site https://packem.github.io/, I get the redirect to https://reactjs.org/docs/static-type-checking.html#typescript

Implement the Runtime Context in TypeScript

It would be appropriate to use TypeScript for extra static checks in the RC. Initially, it would have been ideal to use Packem to bundle itself (more specifically, the RC) as a form of meta programming. However, this can't be achieved if the serializer can't output to Node CJS. These are the disadvantages the RC suffers at the moment:

1. No static types check. Makes debugging a bit of a pain. For documentation purposes, representing the module interface or the module graph as an interface or type alias is more expressive and versatile.
2. Code comments still remain in the npm package, meaning an unnecessary performance drop.
3. Defining a standalone version of the RC that supports legacy code for older browsers is currently impossible.

Some of the issues highlighted above suggest a need for a bundler to bundle the RC. When Packem is stable, it should be able to bundle itself. This means dead code is eliminated ahead of publishing to npm as well.

Forthwith and till we reach stable, we'll just use tsc to handle static type checking and comment stripping.

Broken link

The README.md's "Getting Started" link to https://packem.github.io/docs/getting-started.html results in a 404 error.

WebAssembly version?

Have you considered creating a WebAssembly version of Packem? I’d be curious how fast it is compared to the native versions.

Suggestion: Switch from yaml to json5 for configuration

Yaml does not seem to be that great, there are still many edge cases, it can be hard to edit if the file is large or without editor support and it is less common than json anyway.

My suggestion would be json5 instead, simplified json and with comments.

https://json5.org/

See here for more info about problems with yaml
https://noyaml.com/

No mangling on TypeScript imports

No imports mangling for TypeScript imports

Packem's resolver is not ubiquitous when it comes to mangling imports for custom file types. Originally, it was highlighted in #6, ostensibly, but this issue specifically reflects on the mangler since the bundled outputs don't seem to contain any traces of linking in the module graph.

I used onModuleBundle with a valid TypeScript config built specifically to fit the tsc API. A few of the options for the TypeScript config are listed below:

{
  skipLibCheck: true,
  isolateModules: false,
  suppressOutputPathCheck: true
}

Note: isolateModules was tested and didn't produce better results. The commit on this can be found here.