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

Error: You may need an appropriate loader to handle this file type for shared content #4161

Closed
renatonmendes opened this issue Mar 16, 2018 · 5 comments

Comments

@renatonmendes
Copy link

I´m working with 2 CRA projects. A shared library of components, and the final application myapp. To build this use case I´ve just built a simple shared component:

import React, { Component } from "react";

class SharedComponent extends Component {
  render = () => {
    return <h1>This is a shared component</h1>;
  };
}

export default SharedComponent;

And on myapp project, I do import and use it:

import React, { Component } from 'react';

import SharedComponent from "shared/src/components/SharedComponent/SharedComponent";

class App extends Component {
  render() {
    return (
      <div>
          <h2>Will load shared component...</h2>
          <SharedComponent/>
      </div>
    );
  }
}

export default App;

To use shared inside myapp, I´ve installed shared at myapp folder as:
$ npm install --save ../shared

Doing that I´ve found that node generated a shared symlink inside node_modules folder.

When running myapp I got this error:

$ npm start
../shared/src/components/SharedComponent/SharedComponent.js
Module parse failed: Unexpected token (4:9)
You may need an appropriate loader to handle this file type.
|
| class SharedComponent extends Component {
|   render = () => {
|     return <h1>This is a shared component</h1>;
|   };

This problem is making me crazy. Seens that is something related to symlinks, but I don´t know how to solve. Please advice.

Sampe code:
usecase.zip

@sowhatdoido
Copy link

sowhatdoido commented Mar 16, 2018

It seems link you're right about it being an issue with the symlink:
babel/babel-loader#377

I tried using yarn link instead of local file dependency, but that didn't seem to work either - The JSX isn't being transformed by the loader when it's resolved through a symlink.

Edit: It seems like there is a pretty lengthy discussion about this in a previous issue... you might want to take a look and see if you can't find a resolution:
#1492

Good luck!

@renatonmendes
Copy link
Author

renatonmendes commented Mar 16, 2018

Thanks @sowhatdoido for the useful links.

In fact, I've browsed around tons of posts about symlink problems with CRA, babel and webpack and tried very different things (ejecting, npm link , npm install, creating symlink inside source) and all of them was uneffective (I´m been working around this for some days).

After reading all this stuff and I decided to abandon my approach and move to lerna as officialy recommended from CRA team here.

@sowhatdoido
Copy link

I'm glad you found a solution!

Just for future reference, this issue only occurs when you're trying to create a local file dependency for parallel development in a pre-published phase for both projects. If you can push the shared project to NPM, whether privately or publicly, you can npm install your package and use it without any issues.

One way I would have tackled this problem personally is I would have published shared under a development branch and included it in myapp since I'd assume you don't need to make edits to both apps at the same exact time. If you did you did to make edits at the same time, I would have developed it under the same exact repo for the initial development, then abstracted the code out into shared and myapp at a later point.

@renatonmendes
Copy link
Author

@sowhatdoido This is one approach I´m aware of (publising shared to npm and them installing on newapp). I sill prefer the lerna approach for a monorepo. You can better edit, build, test and git handle modules independently or in a bunch.

Thanks for the comment

@fkopp81
Copy link

fkopp81 commented Nov 14, 2018

I happened on this error with Lerna (using yarn workspaces) when using Babel in multiple packages. I resolved it by adding babel-loader to the nohoist-array in the main package.json.

my-monorepo/lerna.json:

{
  "npmClient": "yarn",  
  "packages": [
    "packages/*"
  ],
  "useWorkspaces": true,
  "version": "0.0.0"
}

my-monorepo/package.json:

{
  "name": "my-monorepo-lerna",
  "private": true,
  "devDependencies": {
    "lerna": "^3.4.3"
  },
  "workspaces": {
    "packages": [
      "packages/*"
    ],
    "nohoist": [
      "**/babel-loader"
    ]
  },
  "engines": {
    "yarn": ">1.4.2"
  },
  "scripts": {
    "electronbuild": "lerna run electronbuild --stream",
    "electrondev": "lerna run electrondev --parallel --stream --bail",
    "webdev": "lerna run webdev --parallel --stream"
  }
}

tony added a commit to tony/cv that referenced this issue Dec 26, 2018
@lock lock bot locked and limited conversation to collaborators Jan 9, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants