Our team recently migrate from Ember App Kit to Ember-cli, one issue is we need to explicitly put import Ember from 'ember'; in almost every file. Is there a recommend way to avoid this? Since we are write an Ember project, Ember is being used in almost every file, IMO it is like you won't need to import System in Java
Related
In all the Angular projects using Material I have worked on in the past, VS Code can never find the name of the module I try to import.
If I try to add, for example, the MatButtonModule to the list of import, VS Code says Cannot find name 'MatButtonModule' and the quick action context doesn't propose to import it.
Up until now, I always had to write the import line manually.
I recently noticed I have the same issue with all their harnesses from the testing cdk.
The baseURL in my tsconfig file is /src and VSCode usually has no issue with any other import. It also work for material components.
import * as mongodbModule from 'mongodb';
The above code is the standard es6 way to import mongodb in nodejs, doing it like so import mongodbModule from 'mongodb' is supposed to throw an error because the mongodb module has no default export; but it still works. I discovered that the mongodb module is a typescript file hence my question.
Whether or not you can write import mongodbModule from 'mongodb' without getting an error depends on your configuration in .tsconfig. In order to enable this, you use the setting --allowSyntheticDefaultImports. As explained in the docs, it's not really that typescript creates the bundle, it's more that typescript assumes that the bundle exists and allows you to import it, while babel handles the actual creation of it.
This flag does not affect the JavaScript emitted by TypeScript, it only for the type checking. This option brings the behavior of TypeScript in-line with Babel, where extra code is emitted to make using a default export of a module more ergonomic. ... For convenience, transpilers like Babel will automatically create a default if one isn’t created.
Excuse the vague title.
I'm trying to build a package to help me use third-party cloud storage APIs (Firebase Storage for example), adding Combine support, etc. This package does the same thing with CloudKit. Everything compiles fine, but when I import the package module into a separate project of mine, the module is apparently missing some public symbols...
Specifically, the ones wrapped inside of an #if canImport(FirebaseStorage) condition. Since Firebase doesn't support SwiftPM yet, this part of the package behaves as expected in the package project itself; it simply skips compiling that whole bit. I figured that a client project that can import this module would compile it fine.
Aside: What I'm trying to do looks something like optional dependencies. I don't want to have to import Firebase to use this package's other features. I have considered splitting the package into separate sub-packages, each depending upon the particular third-party library I want to use. I might do that anyway. But the problem remains that Firebase doesn't yet support SwiftPM (although I hear they're close).
My issue appears similar to this one. My client project just doesn't seem to see the conditioned symbols, though it can import Firebase and FirebaseStorage just fine! I mean that the generated module header is missing them entirely, preventing my client project from compiling when I use them.
It seems to me that the compile condition never leaves the package's own scope of dependent targets. Is this the case? Or am I missing something obvious? I had always assumed that Swift Packages just import and compile the Swift source files into named modules, but now I think that is not so.
Is there a way to build code into a Swift Package that compiles only when the client can import a third-party module that does not yet support SwiftPM? Or does conditional compilation not work that way?
EDIT: Here is the Swift documentation on conditional compilation, for reference.
(Answer from experience in Apr 2020)
It looks like I'm just misunderstanding the compile order.
Importing my packaged module (let's call it CloudStorage) declares a dependency in the client project to that module. Before the client project can compile with its other dependencies, CloudStorage needs to compile without the main project's dependencies. Since CloudStorage doesn't know anything about those dependencies, canImport for those dependencies evaluates to false.
This may have changed in a later version of Swift. I've yet to try again.
canImport checks whether the module name provided can be imported. For swift packages, this evaluates to true if you have provided the module as a target dependency in the package manifest and all of its associated target dependency condition are satisfied.
The benefit of this is this allows you to write code in a platform agnostic way and let your package manifest take care of platform support.
Let's say I have Firebase as a dependency in my target:
.product(name: "Firebase", package: "firebase-ios-sdk", condition: .when(platforms: [.iOS, .macOS, .tvOS])),
I can write my code that depends on Firebase with canImport. Suppose in future firebase-sdk started supporting another platform, I can add the platform to my availability condition and start supporting that platform in my code as well.
But if you don't have the module listed as dependency, even if your client app can import the module, this condition will always evaluate to false. This is due to the sandbox nature of swift package build system and all your package targets are isolated so that consuming client's build settings doesn't affect your package target.
The app I work on takes too long for comfort to compile and to run tests on, so I started creating "feature development projects", which are small projects where I do most of the development (while already under version control for the main project) until I integrate the feature into the project by dragging the new classes and tests into the main xcode project. An issue I have run into is making the main target visible to test files in a universal manner. Lets say we have a project named MyMainProject and a feature project named FeatureProject. For testing in FeatureProject I would have to import everything from the main target (of that project) by doing:
#testable import FeatureProject
That of course won't compile once I integrate the new tests into MyMainProject, which would expect the following (to import the main target of the latter project):
#testable import MyMainProject
My first instinct was to play with the preprocessor to solve the issue, but maybe there is a more elegant way to solve this?
Additional Infromation:
I have Allow testing Host Application APIs checked in General->Testing
I'm currently using ember-cli with ember-qUnit for testing. I would also like to add code coverage results to the test output, so after some research blanketjs seemed the way to go. I installed blanket using:
npm install blanket
And moved the blanket folder into the ember-cli vendor folder. As I understand the way to import libraries is through the Brocfile.js which I am doing like so:
app.import('vendor/blanket/dist/qunit/blanket.js');
Using ember inspector it appears that blanket has been imported correctly, and the "enable coverage" checkbox has appeared at the top of the qUnit test results page. However the tests just hang and just say "running". No tests seem to run. When I use:
ember test -server
It says that it is "waiting for runners". Does anyone know what could be going wrong here?
I've looked around and it seems code-coverage with ember-cli is a tricky subject:
Ember CLI Code Coverage Reports
Thanks
I installed it using ember-cli-blanket. I don't think you need to include it in your Brocfile.js, but instead import it in your tests/index.html after you import your test-support.js.
Blanket will probably make your runners hang for a big as it is essentially loading you entire app all over again.
For what it's worth, I haven't been able to get accurate test coverage using this method yet, but it's possibly user error.