FIles imported from symlinked folders are treated different then others

[dschu-lab]

Description

I'm currently facing problems with importing files from symlinked folders.

Consider this example filestructure

app/
├── core/
│   ├── configuration/
│   ├── Player.js
│   └── GameServer.js
├── client/ << create-react-app
│   ├── build/
│   ├── public/
│   └── src/
│       ├── components/
│       │   └── Game.js
│       └── lib/
│           └── core/ -> ../../../core/ (SYMLINK)

/core/Player.js

export default class Player {
    constructor(
        name,
        color,
        position={x:0, y:0, z:0},
        velocity={x:0, y:0, z:0},
        rotation={x:0, y:0, z:0}
    ) {} 
[...]

/client/src/components/Game.js

import React, { Component } from 'react';
import Player from '../../../lib/core/Player';

class Game extends Component {
    constructor(props) {
        console.log(Player);
    }
}

export default Game;

When having this file in /client/src/lib everything works fine, but when moving the file to the subfolder core, which is a symlink to the root of the project, things start to break.
I'm unfortunately still trying to figure out, what exactly goes wrong, but it must have to do with the webpack configuration, I think. Importing normal configuration objects from this symlink work like a charm, but something is happening (or not happening), when importing classes.

When importing from /client/src/lib console.log outputs the following:

function Player(name, color) {
        var position = arguments.length > 2 && arguments[2] !== undefined ? arguments[2] : { x: 0, y: 0, z: 0 };
        var velocity = arguments.length > 3 && arguments[3] !== …

While, when importing from the symlink /client/src/lib/core console.log outputs the following:

 class Player {
    constructor(name, color, position={x:0, y:0, z:0}, velocity={x:0, y:0, z:0}, rotation={x:0, y:0, z:0}) {....}

Expected behavior

Since I'm technically still in /src I would expect that the code is treated the same way, even though I'm importing from a symlinked folder.

Actual behavior

So some compiling doesn't happen, when importing from symlinks. Is this correct? Should this happen?

Environment

Run these commands in the project folder and fill in their results:

1. npm ls react-scripts (if you haven’t ejected):

xxx@0.1.0 /WebstormProjects/xxx/client
└── react-scripts@1.0.7

2. node -v: v6.11.0
3. npm -v: 3.10.10

Then, specify:

1. Operating system: macOS 10.12.5
2. Browser and version: Google Chrome Version 58.0.3029.110 (64-bit)

Reproducible Demo

Will provide a demo if needed.

[dschu-lab]

Also, when trying to run the build script, it throws this error

static/js/main.dc8f221c.js from UglifyJs
Unexpected token: name (Landscape) [../core/Landscape.js:5,0][static/js/main.dc8f221c.js:140702,6]

This file is written in ES6 using class. How am I able to tell the build script to handle the files the way they should? I've added a .eslintrc inside the ./core folder, but it seems to be ignored.

Update
Found this article on stackoverflow. I've moved everything into a /src folder, creating an ES5 /build and updated my symlink. Worked like a charm 🍾 🥂

[Timer]

Hmm, that's odd! react-scripts should yell at you for importing out of src/; we need to review this.
I imagine we'd want it to work for symlinks.

[dschu-lab]

Thanks for looking into this. If you need a reproducable demo, just ping me. 👍

[gaearon]

I'm afraid but "want it to work" @Timer means we should crash (since we don't currently support this use case). So not sure if it will help you 😛

[Timer]

Yeah, to clarify we'd basically make symlinks within src/ that point outside of something in src/ error out since it's not supported.

I did not mean to imply we'd try compiling these sources (unless that's something we should do (?)). That seems more of a webpack-specific thing, however.

[1st]

The same issue mentioned here #3547

[1st]

Finally I found a workaround. You can run a watch process to compile your shared library and use it as symlink in your project. Here is my gist.

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in 5 days if no further activity occurs.

[stale]

This issue has been automatically closed because it has not had any recent activity. If you have a question or comment, please open a new issue.