Getting an 'Unexpected token' error but all my code looks fine (no IDE errors)

[benjgil]

I've seen this issue a few times, so think it's worth a discussion post about it.

Scenario
Your code looks fine, bit compile runs without a hitch, no IDE errors or issues, but suddenly when running bit start you get an Unexpected Token ... error, on a part of your code that doesnt seem to have any issues with it.

Tl;dr
You're almost certainly trying to reference functionality from a component's internal files directly, rather than from the component's exposed API (i.e. exported members in its index file).
So if you have any code of the format import {something} from '@org/scope.some.namespace.componentName**/fileName**' then you'll need to refactor to:
import {something} from '@org/scope.some.namespace.componentName'.

Re-compile and the error should go away on your next bit start.

Confirming the Diagnosis

There are two giveaways that this is indeed the problem.

1. You have a second / in the import path. The component name will always be just a succession of .'s after the initial /, so if you have another / in your import path then you're accessing some internal file in the component, rather than its exposed API
2. You have TS syntax in the file snippet in the terminal printout of your bit start error - webpack is always meant to output pure javascript in the bundle, so if some typescript got in there it's because webpack bundles up some ts in there too by mistake (e.g. it wasn't configured to deal with untranspiled imports) and that's what's causing the error.

Why does this happen?
Generally webpack knows to bundle up the dist output of a dependency, which will always be javascript. For anything that isn't pure javascript - or is a flavour of javascript which needs some pre-compilation - webpack needs a loader to be configured in order to convert the input into something that can be bundled and will be recognised by browsers.

When you import a dependency via it's main file (generally index.[j/t]s) webpack knows to fetch that component's compiled dist files and add them to the bundle it creates. However when you access a specific file inside a dependency, webpack doesnt know what that file is written in, and unless a loader has been added to pre-compile/transpile that file, non-javascript code will get into your bundle.

The way to ensure that this never happens is to always import items via the component's exposed API, i.e. via its entry/main file.

N.B. you can get round this by referencing a component's dist folder directly, but this can also have some unexpected consequences and is highly discouraged.
In general, if you find that you need to access some internal functionality of a component which hasn't been exposed via the API, then that's almost always a bad sign for the design of either your code (are you meant to need that functionality?) or the API of the imported dependency. We would recommend trying to solve the import requirement via changes to either of the above before resorting to directly referencing internal dist files of a package.