Skip to content
This repository has been archived by the owner on Mar 13, 2024. It is now read-only.

Support more syntaxes and import styles #60

Closed
voxpelli opened this issue Jan 27, 2017 · 4 comments
Closed

Support more syntaxes and import styles #60

voxpelli opened this issue Jan 27, 2017 · 4 comments

Comments

@voxpelli
Copy link
Collaborator

voxpelli commented Jan 27, 2017

To support more types of syntax we would have to do some changes. Without deciding on if we should do any changes, it would be great to discuss what changes we could make to support what things.

We're currently relying on detective, which in turn relies on acorn. Neither supports anything but ordinary javascript.

Alternative 1: Switch the detective module – the complex one

An alternative would be to swap this for a Babylon-based setup, through something similar to detective-es6 (although something a bit more configurable than that one, either by making a PR to that module or starting out by prototyping the same < 40 lines of code in this project). This is similar to the approach in #45.

Things a Babylon-based approach would support:

Alternative 2: Pluggable detective – the simpler one

This is probably the simplest one: We could just make the built-in detective() call swappable for a custom detective() call that could be provided by a third-party module, such as detective-es6.

dependency-check --detective detective-es6

Could then result in something like:

var customDetective = opts.detective
  ? (typeof opts.detective === 'string' ? require(opts.detective) : opts.detective)
  : false
var requires = (customDetective || detective)(contents)

Things a pluggable approach would support:

  • Everything

Alternative 3: Transform the files

This is the solution suggested in #40, I'm a bit unsure about the advantages between this and Alternative 1. Seems like it eg. requires storing the transforms somewhere temporary and that it have some other complexities.

Alternative 4: ??

...

Summary

I'm leaning towards Alternative 2. Any thoughts @blakeembrey, @maxogden?

It would enable solving eg. #37, #16 as well as enable #45 to work without committing to that specific solution.

It should be able to solve #46, #57 and #59 as well as long as there's some detective-like implementation for their respective syntax.

@voxpelli
Copy link
Collaborator Author

Alternative 2 is similar to what node-sass does with it's --importer extensions: https://github.com/sass/node-sass#importer--v200---experimental

@blakeembrey
Copy link
Collaborator

blakeembrey commented Jan 27, 2017

I think it's probably safer to keep this module away from the syntax trees. Instead, I was thinking something like your detective approach: dependency-check --detective typescript --detective sass. It's likely we could also change how the dependency list is selected too (for jspm or bower, for instance: dependency-check --package bower).

@blakeembrey
Copy link
Collaborator

One thing that might be tricky is the input locations. Since transpiled output is not usually related to input. Also, the above having two --detective might not work and best to support only one initially - I was think about situations where people might be using a mix of TypeScript and JavaScript, but the smallest step would just to call dependency-check twice there (maybe support globs or something later over --entry).

@voxpelli
Copy link
Collaborator Author

I'm +1 on just supporting a single --detective option – if anyone wants to support multiple syntaxes at once, then they can just make a function with the detective syntaxes that itself handles the lookup for both – either by calling multiple detective modules itself or by doing something completely different.

I will do a PR for this alternative.

I would suggest making a separate issue for pluggable dependency lists.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

No branches or pull requests

2 participants