WIP Renamed node-bindings and added a dedicated entry point for wasm

[alshdavid]

↪️ Pull Request

• Moved node-bindings to parcel_napi
  • Put existing code under src/parcel_v2
  • Will remove parcel_v2 or migrate code into new context as we progress
• Created parcel_wasm package to be an entry point for wasm consumers
• Moved wasm code from node-bindings into parcel_wasm

💻 Examples

🚨 Test instructions

✔️ PR Todo

• [ ] Added/updated unit tests for this change
• [ ] Filled out test instructions (In case there aren't any unit tests)
• [ ] Included links to related issues/PRs

[devongovett]

Why? Isn't parcel_wasm mostly a duplicate of the napi bindings? There's only a few differences that were covered by conditional compilation before.

[alshdavid]

Why? Isn't parcel_wasm mostly a duplicate of the napi bindings? There's only a few differences that were covered by conditional compilation before.

I'm thinking of abstracting those peices out on their own and share them between parcel_nodejs and parcel_wasm (which function as entry points for those targets).

For instance, the Resolver implementation can be moved into parcel_plugin_resolver/napi_bindings/parcel-v2 and gated via crate features wasm or nodejs.

This would avoid duplication, allowing the Resolver code to remain largely unchanged whist splitting the wasm and nodejs entrypoints up.

In the end state the binding layer will be significantly lighter so this will be replaced

[devongovett]

But why do we even need separate entry points for them in the first place if they are both using napi?