CocoaScript icon indicating copy to clipboard operation
CocoaScript copied to clipboard

CommonJS and npm integration

Open jacobrask opened this issue 10 years ago • 6 comments

Allowing require() in addition to the import macro would enable you to use a bunch of modules from the npmjs repository in your CocoaScript code.

If a depended on module is using Node APIs it would obviously not run in a CocoaScript environment, but a lot of the modules in npm are simple cross-platform JavaScript libraries like underscore.js.

CocoaScript modules could be submitted to npm, and you have a package manager for free.

jacobrask avatar Jun 10 '14 21:06 jacobrask

Is there any way to use CommonJS or npm modules in CocoaScript for now? @jacobrask

NickolasHu avatar Jan 14 '16 07:01 NickolasHu

No there isn't.

ccgus avatar Jan 15 '16 18:01 ccgus

Yes you can: https://github.com/mathieudutour/sketch-builder

mathieudutour avatar Nov 25 '16 15:11 mathieudutour

Neat

ccgus avatar Nov 25 '16 16:11 ccgus

@ccgus I worked on this a bit and have a POC working in Sketch, going to be released in 49.

Basically, I added a require global. It is kind of the counterpart of the @import syntax of CocoaScript but for working with node packages: you need to use module.exports to expose what you want, it doesn’t pollute the global scope, it is dynamic, etc.

For now, it has a very simple resolver algorithm:

  • I maintain a list of core modules that Sketch ships with. For now, there is only sketch.
  • If the path starts with a ., it’s a relative path and I’m looking for a js file starting from the command file.

So it doesn’t handle nested relative require very well (it's working if you have your require in the top level; but not if they are in a function, it will look for the package starting from where the function is executed), nor looking for a node_modules folder.

In parallel, I started to create a few packages to mirror the NodeJS API: fs to replace the use of NSFileManager, child_process for NSTask, etc.. The goal is multiple:

  • provide an easy to use API: the NodeJS API has been created with JavaScript in mind, callbacks make a lot more sense than error pointers, obj-c delegates are a pain to use, etc..
  • Those APIs are the basic building blocks that you need pretty much all the time. If we manage to control their quality (well tested, correct error handling, nice async usage, argument sanitization, etc.), we can hopefully raise the quality of the entire plugin ecosystem.
  • The docs are already done :)
  • Complete NodeJS compatibility! Imagine being able to install any npm packages without worrying whether it’s using some node API!

Later, when those packages are finished, we will probably ship them with Sketch directly.

I understand that it's vision that might not match the one you have for CocoaScript so I preferred asking here if it's worth for me creating a PR to upstream this or not.

mathieudutour avatar Jan 24 '18 17:01 mathieudutour

Yep, make the PR. This would be pretty cool to have.

ccgus avatar Jan 25 '18 18:01 ccgus