packem / packem Goto Github PK

View Code? Open in Web Editor NEW

604.0 16.0 8.0 5.78 MB

📦⚡ A precompiled JavaScript module bundler

Home Page: https://packem.github.io/

License: MIT License

JavaScript 100.00%

packem build-tool rust bundler compiler plugin prebuilt-binaries javascript minify code-splitting

packem's Introduction

Packem

Packem is an extensively precompiled general-purpose JavaScript module bundler with a focus on performance, flexibility and extendibility. Its crust is built with Rust, a zero-cost abstraction systems programming language with guaranteed memory safety.

Note: This is a pre-release version. Do not use it in production.

Build Status

Since the v0.2 release, prebuilt Packem binaries are available for UNIX systems only. Binaries for Windows are not available for versions below v1.4.

Windows	macOS	Linux (Ubuntu)
❌	✔	✔

Additionally, Node 12 shipped a more stable implementation of the N-API which does not synchronize with the bindings implemented for the LC. For that reason, only the current versions of Node are battle-tested:

Node 10	Node 9	Node 8
✔	✔	✔

Why Packem?
Installation
Plugins
Further Reading
Contributing
FAQ
License

Why Packem?

Hypersonic speeds that go +2X faster than ParcelJS.
Light and efficient outputs.
Unique configuration style that will not make you cry.
Code Splitting with dynamic imports.
Comprehensive & versatile plugin API with an elegant approach.
Common plugins for smoother development experience.

Packem (v0.1.3-alpha) is +2X faster than Parcel (v1.12.3 - with multicore compilation).

Modern bundlers today do optimize your code heavily, minify them and create near-perfect bundles but it comes at an expensive cost, time. The time slice is worth the effort to boost your productivity and not unnecessarily spending too much time on the tool.

Packem's real power lies in its usage of Rust, which is the state-of-the-art in high performance solutions. This delivers close-to-the-metal speed when compared against other bundlers without comprimising features.

In a comparison of Packem against Parcel, each bundler had to compile the entire Lodash v4.17.1 to a single bundle and this was the results of the speed test:

Test No.	Packem	Parcel
1	4.23s	11.01s
2 (cold)	5.12s	12.39s
3	4.55s	11.80s

Note

Packem v0.2 uses a faster method of parsing the module graph using V8's JSON.parse() on larger graphs, making it upto 1.2-2.0x faster than previous versions.

Installation

Packem is distrubuted as an npm package, so you can install it globally by executing the following command:

# Default installation method (with npm)
npm install -g packem

# For Yarn, run
yarn global add packem

Checkout the Getting Started guide for more details.

Plugins

Packem uses a comprehensive class-based event system. Based off of this, plugins are instantiated in order of definition in the configuration during build time. Built-in events are also rehydrated into the plugins which they can hook onto using the PackemEventDispatcher API. More details on this can be found in the Plugins API.

Most of the common plugins are not included with a single installation of Packem and will require you to install them manually. Some of these common plugins include:

dev-plugin - An abstraction of Packem's development toolkit i.e. the development server, watcher and other development utilities. This means, in essence, Packem doesn't enforce development tools by default.
file-plugin - Loads common structural and text-based file formats to their appropriate equivalents in JavaScript like plain text files to strings & YAML files to their respective JSON object representations.
minify-plugin - Uses terserjs to crunch and optimize your JavaScript into tiny obfuscated files and write it to the output path.
style-plugin - Responsible for bundling SASS/SCSS, LESS & PostCSS to plain CSS which is then injected into the webpage at runtime.
image-plugin - Processes a PNG, JPG/JPEG, GIF, WebP or SVG file, compresses it with a few options like quality, compressionRatio and dithering to create efficiently optimized images that still retain fidelity.
bundle-stats-plugin - Checks if your bundles exceed a certain customizable constraint/limit and issues tabular diagnostics with details like bundle size vs the pre-defined limit.
markdown-plugin - Transforms a Markdown file into escaped HTML and then returns the result into the bundling pipeline.
coffeescript-plugin - Compiles CoffeeScript to JavaScript then appends it to the mainstream bundle.

Contributing

Packem is a community-led project. We depend on your contributions to sustain this project through financial support, filing issues and presenting PRs. Check the contribution guidelines for more details.

FAQ

Check the FAQ page to get help on some common caveats.

Contributors

Code Contributors

This project exists thanks to all the people who contribute. [Contribute].

Financial Contributors

Become a financial contributor and help us sustain our community. [Contribute]

Individuals

Organizations

Support this project with your organization. Your logo will show up here with a link to your website. [Contribute]

License

This project is licensed under the MIT License.

packem's People

Contributors

Stargazers

Watchers

Forkers

admbradford ksxgithub obooman ezard aircom-inc opencollective brandboxmarketplace maxjduhart

packem's Issues

Broken link

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

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

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)

Question: Where is the rust code?

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

WebAssembly version?

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

No mangling on TypeScript imports

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:

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.
Code comments still remain in the npm package, meaning an unnecessary performance drop.
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.

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.

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/

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

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.

packem / packem Goto Github PK

packem's Introduction

Packem

Build Status

Table of Contents

Why Packem?

Installation

Plugins

Further Reading

Contributing

FAQ

Contributors

Code Contributors

Financial Contributors

Individuals

Organizations

License

packem's People

Contributors

Stargazers

Watchers

Forkers

packem's Issues

Recommend Projects

Recommend Topics

Recommend Org