Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accept a transforming function as an option #165

Closed
bmancini42 opened this issue Apr 19, 2017 · 8 comments
Closed

Accept a transforming function as an option #165

bmancini42 opened this issue Apr 19, 2017 · 8 comments

Comments

@bmancini42
Copy link

bmancini42 commented Apr 19, 2017

It would be nice to have an additional option possibility for using a transforming function on the path. RegExs are suitable for most situations, but sometimes you want to have a smarter transformation.

In my case, I had been using a webpack resolver function to basically:

1 - Find a reserved string in the old path
2 - Replace the reserved string with a configured param
3 - If that transformed file exists, use it as the new path
4 - Otherwise, use a fallback path

This requires processing specific to each path, rather than just a simple transformation you could do with the same RegEx to all paths.

I happened on the idea of using this plugin to do this instead, since my ava tests were not using webpack's resolve plugin, but this would require that this plugin be extended to allow for a transforming function as an option.

cf #164

@tleunen
Copy link
Owner

tleunen commented Apr 19, 2017

Thanks @bmancini42, now that Babel 7.0 will support a javascript file as a configuration file (.babelrc.js), I can see this being interesting for some users, indeed.

This can be tricky though.

Let's say you have a root configuration. Do you want to apply a global transformation on the files matching it as well? Only for alias? Should we offer the ability to setup a global transform function, or only targeted one based on one alias?

@fatfisz
Copy link
Contributor

fatfisz commented Apr 21, 2017

I was thinking that implementing pre- and post- hooks would be the solution to this problem, but maybe allowing the use of a custom getRealPath doesn't sound so bad? It would get the sourcePath, the file and the opts, so it would be up to the custom implementation to handle those properly. The original method could be passed as an additional argument:

{
  plugins: [
    ['module-resolver', {
      getRealPath(sourcePath, { file, getRealPath, opts }) {
        // Implement your own getRealPath, possibly using the original method
      }
    }]
  ]
}

@tleunen
Copy link
Owner

tleunen commented Apr 23, 2017

Hmm... Yep, I'm not a huge fan of pre/post. It can become really complicated with these things.
Giving the entire function signature, why not... (maybe with the simple name "transform" instead?)

This lead me to think about what you said in another ticket @fatfisz... Should we execute the alias resolver on the root config? :D

Let's say we provide the custom transform function. If the user specify a root config + function (if we allow this), should we run the fn on the root as well? What do you think?

@bmancini42
Copy link
Author

My thought was that it would take place whenever aliasing takes place -- after roots, I guess. If you think of alias as being a transform function that only applies a regex, this is a transform function that happens at the same time but allows you more freedom.

@bmancini42
Copy link
Author

bmancini42 commented Apr 25, 2017

If I understand correctly, you can do this pre-Babel 7 also, by using the babel-register pkg? Maybe I'm wrong on that, but it seems to work for other plugins. (this may only work if using a secondary processor, in this case ava)

@tleunen
Copy link
Owner

tleunen commented May 8, 2017

Yes, babel-register allows you to setup the config in js. I'm not sure how well it works with this plugin though.

Anyway, I believe it's good to provide a transform function and we could even go further and allow a string to a path, or a function.

My only concern is to put that at the right place in the code. I'd say that the custom transform should replace everything (root and alias). I don't really know if offering the default root/alias transformers would make sense.. @fatfisz, any thoughts?

@fatfisz
Copy link
Contributor

fatfisz commented Jun 5, 2017

I think that it should be either the getRealPath form module-resolver or the custom one, at least as a start.

@fatfisz
Copy link
Contributor

fatfisz commented Jun 11, 2017

@tleunen After #194 is merged we would be able to go forward with this like so:

  • the original getRealPath as defined in module-resolver is exposed in the module, so there's no need to pass it as through arguments (i.e. use import { getRealPath } from 'babel-plugin-module-resolver')
  • the signature should probably be the same for the exposed getRealPath, so that passing the original to the options would be the same as not passing anything at all; the signature is getRealPath(sourcePath, currentFile, opts)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants