Should be possible to force import of "unused" modules in case there are side-effects

TypeScript Version:

1.8.10

Code

MyService.ts

// A self-contained demonstration of the problem follows...
import {ngModule} from './../module.ts';

export class MyService {
}

ngModule.service('myService', MyService); // <- REALLY IMPORTANT SIDE-EFFECT

MyComponent.ts

import {MyService} from './MyService.ts';

class MyComponent {
  constructor(private myService: MyService) { }
  // ...
}

Expected behavior:
(I know this sort-of-tree-shaking is "by design", but by the principle of least astonishment, expected behavior is this)

MyComponent.js

var MyService_1 = require('./MyService');
var MyComponent = (function() {
  function MyComponent(myService) {
    this.myService = myService;
  };
  // ...
})();

Actual behavior:
MyComponent.js

var MyComponent = (function() {
  function MyComponent(myService) {
    this.myService = myService;
  };
  // ...
})();

And then AngularJS is all "myServiceProvider not found" and crashy.

It's possible:

import './MyService`;

I know I can do that, but I shouldn't have to say

import './MyService';
import {MyService} from './MyService';

all over the place. It's just untidy.

:)

I am too dumb for getting why import {MyService} from './MyService'; would not work, please enlighten.

please see https://github.com/Microsoft/TypeScript/wiki/FAQ#why-are-imports-being-elided-in-my-emit

Aleksey-Bykov

Aleksey-Bykov Basically, in Angular code, the class is instantiated by the dependency injection system, so you import MyService but then you don't new it or anything, you just use it as the type for the injected parameter. TypeScript sees that you don't actually use the class except as a type declaration, which has no meaning in the emitted JavaScript, so it sees no reason to include it in the emitted JavaScript. It makes perfect sense, except when the file you are importing from has side-effects; in this case, the registering of the service with an AngularJS module.

While I get understand the use case, I can't conceive of a clean syntax that would denote that the import should not be elided... Only except maybe:

import *, { MyService } from './MyService';

In that the compiler would understand that the anonymous * is denoting that the import is being doing for side-effects but not being named. Therefore:

import * from './MyService';
/* is equivalent to */
import './MyService';

The one "edge case" is that if the default export of the module being something that gets erased (is that even possible to export default something that is erasable)?

@markrendle for what it's worth, this is my pattern for registering services in angular 1.x:

my-service.ts

export class MyService { 
    static $inject = ['$q'];
    constructor(readonly $q: ng.IQService) {}
}

my-other-service.ts

import { MyService } from './my-service';

export class MyOtherService { 
    static $inject = ['MyService'];
    constructor(readonly myService: MyService) {}
}

app.ts

import { module } from 'angular';
import { MyService } from './my-service';
import { MyOtherService } from './my-other-service';

const app = module('app', [])
    .service({
        MyService,
        MyOtherService
    });

export default app;

main.ts

import { bootstrap } from 'angular';
import app from './app';

bootstrap(document.body, [app.name], { strictDi: true });

This ensures the service import will not be elided. It also has the advantage of decoupling your service classes from angular (sure $inject is there but they don't depend on angular).

Edit: Updated example with explicit export from "app.ts"

Aluan Haddad (@aluanhaddad)

Aluan Haddad (@aluanhaddad) I see what you've done there, but I use ngAnnotate as part of my build process so I don't have to manually maintain $inject properties, and I don't think ngAnnotate would pick up that way of adding services... although I'll give it a try.

This would all go away if my boss would just let me spend 6-9 months rewriting the entire application in Angular 2...

@markrendle I don't use ngAnnotate so I wouldn't know if that would work but the only reason I write my "services" as classes registered with .service instead of factories registered with .factory is to take advantage of the static inject notation. That said, I only used the above style for my example because it is my preference.

My example was just meant to show that you don't have to register each service in the module where it is defined. I also think that there are compelling reasons to avoid doing so.

Regardless, using a tool like ngAnnotate shouldn't dictate the way in which you structure your code or the order in which you register your services.

Aluan Haddad (@aluanhaddad)

Regardless, using a tool like ngAnnotate shouldn't dictate the way in which you structure your code or the order in which you register your services.

Aluan Haddad (@aluanhaddad) But it does, because it makes life so much easier that I'm willing to put up with its demands.

So, any work around?!

Kayvan Arianpour (@karianpour)

Kayvan Arianpour (@karianpour), to the original issue in this thread yes, just do double import once of the type and once just of the module with no types, look at the start of the thread for details

Preserve all typescript imports, not only .svelte

I use export * from './MyService' where myservice.ts exports default like export default class MyService {}.
It doesn't reexport anything but it do force to execute the side-effect codes.

If you use barrel files(index.ts which re-exports module), every file must export an empty default value as below, to prevent tree-shaked by ts compiler.

index.ts

export * from './a';
export * from './b';   
export * from './c';
export default {}; // <- this is required

PS: I prefer export * from './MyService' rather than import './MyService' because the former reports a error path while the latter doesn't.

In MainFilter.ts I use import { conf, IData } from './MainFilter.conf'; and in dev-mode for browser use <script type="module">
MainFilter.conf.ts has interface IData:

export interface IData {
	class: string;
	orderNumber: string;
}

In browser console I have an error:
Uncaught SyntaxError: The requested module './MainFilter.activity.conf.js' does not provide an export named 'IData'
cause of tsc cutting out interface export from MainFilter.conf.js =(
How to solve it? Why MainFilter.js not cutted out IData?

Solved as

import { IData } from './MainFilter.conf';
import { conf } from './MainFilter.conf';

but forced to off import/no-duplicates rule =(

FYI, I have a PR open to fix this at #35200. Feedback is welcome from anyone still interested in this issue. Thanks!

This keeps tripping me up, so I thought I'd note it here.

This code breaks when the elem2 line is commented out:

import ClipboardCopyElement from "@github/clipboard-copy-element";

const elem1: ClipboardCopyElement = document.querySelector("clipboard-copy");
const elem2 = new ClipboardCopyElement();

Unfortunately, I find this is a pretty common situation when working with custom elements, and as a library author I'm frustrated that I can't fix this for library users. It also makes it trickier to recommend TypeScript to beginners. The only way to allow elem2 to be commentable in the code above is to change the imports to the following, which I think should be considered an anti-pattern (I would flag it in a code review):

import "@github/clipboard-copy-element";
import ClipboardCopyElement from "@github/clipboard-copy-element";

Given that TypeScript will probably treat import ClipboardCopyElement like import type ClipboardCopyElement in the foreseeable future, it would still be really useful to have "import with side effects" (ideally still compatible with normal JS syntax). This:

could be used in foolproof sample code, and
could still support some tree shaking, as pointed out at Should be possible to force import of "unused" modules in case there are side-effects #9191 (comment) .

(Ideally, I'd love to have tooling that encourages the use of import type when possible, and keeps ESM semantics for importing objects.)

Lately my eye caught a compiler/tsconfig option called importsNotUsedAsValues when I was browsing the TSConfig Reference on the TypeScript website. Perhaps this issue here is solved when specifying the value preserve or error for that option?

[tsconfig.json] Enforce that type-only imports must be used with `imp…

Sorry if I'm confused about why this is closed. This hasn't been fixed, has it?

It would be nice to have something that is the opposite of import type that tells TypeScript we want to actually import the file, even if the things we're importing just so happen to be types.

Right now, we have to do this:

import type { MyType } from './file';
import './file';

Is there a way to shorten this? If not, maybe something

import value { MyType } from './file';

import type indicates we only care about these imports in type space, and import value tells TypeScript that there is something in file.ts that we need in value space.

Ricky Miller (@richardkazuomiller)

Ricky Miller (@richardkazuomiller) I think you want to set the option importsNotUsedAsValues: preserve

With this, all your imports will be kept, only explicit import type will be removed.

jods (@jods4)

jods (@jods4) Thanks, that looks like it might do the trick 😄

Add registerall, clean up exports

Navigation Menu

Repository navigation

Should be possible to force import of "unused" modules in case there are side-effects #9191

63 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Should be possible to force import of "unused" modules in case there are side-effects #9191

Description

Activity

RyanCavanaugh commented on Jun 15, 2016

ThatRendle commented on Jun 15, 2016

ThatRendle commented on Jun 15, 2016

zpdDG4gta8XKpMCd commented on Jun 15, 2016

mhegazy commented on Jun 15, 2016

ThatRendle commented on Jun 16, 2016

kitsonk commented on Jun 16, 2016

aluanhaddad commented on Jun 17, 2016

ThatRendle commented on Jun 22, 2016

aluanhaddad commented on Jun 22, 2016

ThatRendle commented on Jun 22, 2016

63 remaining items

karianpour commented on Jun 9, 2019

swar30 commented on Jun 9, 2019

whzx5byb commented on Oct 28, 2019

viT-1 commented on Oct 29, 2019

viT-1 commented on Oct 29, 2019

andrewbranch commented on Nov 27, 2019

lgarron commented on Apr 27, 2021

Bart76 commented on Apr 27, 2021

richardkazuomiller commented on May 11, 2021

jods4 commented on May 11, 2021

richardkazuomiller commented on May 11, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions