Skip to content
This repository has been archived by the owner on Feb 19, 2020. It is now read-only.

Inconsistent generated output #70

Open
ssilve1989 opened this issue Apr 24, 2018 · 4 comments
Open

Inconsistent generated output #70

ssilve1989 opened this issue Apr 24, 2018 · 4 comments

Comments

@ssilve1989
Copy link

Hi,

Given the following import statement

import { promisifyMeteorCall } from 'imports/utils/meteor';

and the following tsconfig.json

{
  "compilerOptions": {
    "allowJs": true,
    "allowSyntheticDefaultImports": true,
    "alwaysStrict": true,
    "baseUrl": ".",
    "jsx": "react",
    "lib": [
      "es2017",
      "dom"
    ],
    "paths": {
      "*": ["*"],
      "imports/*": ["imports/*"]
    },
    "module": "commonjs",
    "moduleResolution": "node",
    "noImplicitAny": false,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "pretty": true,
    "removeComments": true,
    
    "sourceMap": true,
    "target": "es5"
  },
  "include": [
    "client/**/*",
    "server/**/*"
  ],
  "exclude": [
    "node_modules",
    ".meteor"
  ]
}

An error occurs saying

Unable to resolve some modules:

  "imports/utils/meteor" in /Users/ssilvestri/dev/trumid/studio/packages/ui/imports/components/Buttons/SystemRefresh.js (web.browser)

What's interesting here is the generated code, for the imports look as follows:

var React = require("react");
var meteor_1 = require("imports/utils/meteor"); // <---- the outlier
var Button_1 = require("material-ui/Button");
var Dialog_1 = require("material-ui/Dialog");
var Typography_1 = require("material-ui/Typography");
var styles_1 = require("material-ui/styles");

which of course makes sense, imports/utils/meteor doesn't make sense here so of course it can't resolve it. But if we look at all the other modules that have been generated from TypeScript we see this imports similar to this

var FieldComponents_1 = require("/imports/components/Form/FieldComponents");

where the statement has been translated to have a / in front, which meteor understands.

Why are some being transformed into the statements with a leading slash and others not?

@barbatus
Copy link
Owner

Likely a bug. What if you test this import from a file with another name (say imports/utils/test i.e. not meteor) does it work?

@ssilve1989
Copy link
Author

Hm, the initial import statement seems to work now, I'm not sure what dependencies have been updated since I opened this that would change the behavior 😕

@ssilve1989
Copy link
Author

@barbatus now failing again with other import statements that look like imports/logger

@barbatus
Copy link
Owner

barbatus commented Jul 6, 2018

sorry was not following issues in this repo last month
if still an issue what if you put one level deeper i.e. imports/../logger is it still failing?

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

2 participants