After successfully optimizing and building the modules using r.js library, you would find the file build.txt with the summary of all the modules and its dependencies.
I don't want this build.txt file to reach the production server.
Apart from manually deleting the build.txt, is there any way to suppress or remove this file?
Manual deletion is not the answer that I am looking for as you might forget to delete it sometimes.
As I understood the source code, there is no way to prevent the creation of the build.txt.
This feature has been requested: https://github.com/jrburke/r.js/pull/722/files
To use it, you would add the following option to your build.js file:
noBuildTxt: true
As Louis points out, it hasn't actually been added :/
If you want, you can do what I did and restructure your application so you don't need a modules property, add the noBuildTxt option and then pretend it works. (Removing the modules property was what got rid of the module definitions, not the noBuildTxt)
Related
I've got a fairly stock stack based project that uses proto-lens-setup to generate some Haskell code from some .proto files. I'm using haskell-language-server with wonderful success in emacs for everything except when my code imports any of the Proto.Myproto modules. It can't find them and thusly can't properly check the files I'm editing.
The project builds perfectly, but I'd like to have the lsp working. It's very helpful!
I get errors highlighted anytime my code uses an identifier from the proto-lens-generated code. I've tried looking into hie-bios configurations but didn't see anything obvious to put in a manual config to make it work. I don't normally have a manual hie-bios config.
I am attempting to convert parts of an Android app to iOS using Doppl, and I am getting a strange result: Doppl keeps trying to pull in android.arch.lifecycle:reactivestreams, even though I don't want it to.
Specifically, in app/build/j2objcSrcGenMain/android/arch/lifecycle/, there is a reactivestrams/ subdirectory with R.h and R.m files in it. This seems to make Xcode cranky and may explain why I had some oddities with pod install.
My app/build.gradle has compile "android.arch.lifecycle:reactivestreams:$archVer", because my activity is using LiveDataReactiveStreams.fromPublisher(). However:
The activity is not in the translatePattern (and since its code is not showing up in app/build/j2objcSrcGenMain/, I have to assume that the translatePattern is fine)
I do not have a doppl statement related to reactivestreams, because there does not appear to be a Doppl conversion of this library (nor should it be needed here)
AFAIK, nowhere else in this app am I referring to LiveDataReactiveStreams, which AFAIK is the one-and-only public class from the reactivestreams library
So, the questions:
What determines whether Doppl creates R.h and R.m files for some dependency? It's not the existence of a doppl statement, as I have doppl statements for a lot of other dependencies (RxJava, RxAndroid, Retrofit) and those do not get R.h and R.m files. It's not whether the dependency is referenced from generated code, as my repository definitely uses RxJava and Retrofit, yet there are no R files for those.
How can I figure out why Doppl generates R.h and R.m for reactivestreams?
Once I get this cleared up... do I re-run pod install, or is there some other pod command to refresh an existing pod with a new implementation?
Look into 'app/build/generated/source/r/debug' and confirm there's an R.java being created for the architecture component. It'll be under 'android/arch/lifecycle/reactivestrams'.
I think there are 2 problems here.
Problem 1
Somehow Doppl/J2objc is of the opinion that this file should be transpiled. It could be either that 'translatePattern' matches with it, or that something in the shared code is referencing it. If you can't figure out which, please post a comment and I'll try to help (or post in slack group).
Problem 2
Regardless of why that 'R.java' is being sucked into the translate step, because of how stock J2objc is configured, the code is being generated with package folders instead of creating One Big Name. That generated file should be called 'AndroidArchLifecycleReactivestramsR.h' (and AndroidArchLifecycleReactivestramsR.m). Xcode really doesn't like package folders. That's why there's a slightly custom J2ojbc being used with Doppl, so we can have files with big names instead of folders.
In cases where you intentionally use package names that match with what J2objc considers to be "system" classes, you need to provide a header mapping file to force long names. The 'androidbase' doppl library needs to add a lot of files that are in the 'android' package, which J2objc considers "system". We override those names in the mapping file.
build.gradle
https://github.com/doppllib/core-doppl/blob/master/androidbase/build.gradle#L19
mapping file
https://github.com/doppllib/core-doppl/blob/master/androidbase/src/main/java/androidbase.mappings
I screwed up.
In my dopplConfig, I have:
translatePattern {
include '**/api/**'
include '**/arch/**'
include '**/RepositoryTest.java'
}
In this case, **/arch/** not only matches my arch package, but also the arch package from the Architecture Components.
Ordinarily, this would not matter, because the Architecture Components source code is not in my project. But, R.java gets generated, due to resources, and the translatePattern includes generated source code in addition to lovingly hand-crafted source code. So, that's where my extraneous Objective-C was coming from.
Many thanks to Kevin Galligan for his assistance with this, out on the #newbiehelp Doppl Slack channel!
I have a library coming up deep in the node module hierarchy which is causing security issues. I am not directly referencing that module in my package.json. One of the module which I reference is loading up another module and that module is loading this module. So it's the third layer in the dependency tree. I can find out the library dependence tree using npm ls.
I tried updating package.json, but that's not correct I think.
How can I update the version of this particular module without touching the top modules? Should I have to use shrinkwrap?
One (horrible way) (to answer your question directly) you could carefully manage all of those dependencies on your own and build that structure outside of NPM. I hate it. There is a ton of dependency management overhead and no guarantee any of the hand assembled components would work together - so testing overhead too. but in "theory" it could work. FWIW I don't think shrinkwrap helps with sub dependencies at all.
I recommend this course (I understand this isn't what you asked for - but it is the best approach IMO):
Fork/Branch the library and make the change there.
Then issue a pull request (Back to the main branch)
Until it is is merged back in, you cab reference it via the GIT url in your package.json
from: https://docs.npmjs.com/files/package.json
git+ssh://git#github.com:npm/npm.git#v1.0.27
git+ssh://git#github.com:npm/npm#semver:^5.0
git+https://isaacs#github.com/npm/npm.git
git://github.com/npm/npm.git#v1.0.27
Working on the new android side of extensions with the changes. I have my separate extension as its own dependency.
In my code I require references to the Extension.Java class as well as the HaxeObject.
These are located in extensions-api, which is it's own separate dependency.
I've tried including these files in my own dependency, this causes top-level exceptions because a number of the Java files were included twice. I've also tried not including the extensions-api, this works to some extent, however If in the future I decide to use more extensions this won't work (less than ideal).
I need to find a way to reference these files from one dependency to another. so from: MyExtension.src.org.haxe.nme.MyExtension and extension-api.src.org.haxe.nme.Extension
So I guess the point I'm stuck at is how I make these two dependencies see each other whilst compiling so that when they merge to make the .dex file they don't cause top-level exceptions.
I could potentially hack it by placing my extension into the extension-api folder. Something like:
<dependency name="extension-api" path="dependencies/MyExtension" if="android"/>
The issue with this being that the androidManifest merging wouldn't work.
I found the answer here:
the gist is in the project.properties file you want to add the line:
android.library.reference.1=../extensions-api
http://www.openfl.org/community/general-discussion/native-extensions/
In an attempt to separate my .ts source files from the .js output, I'm trying to implement a formal file-watcher in TypeScript and it seems as though the ability to specify an output path for a single file does not exist.
The flow, just to be clear: I begin watching my entire src directory, make a change to, say, src/views/HomeView.ts, and i want node to pick up that the file has been changed, and move the compiled version to public/js/views/HomeView.js.
Using tsc myfile.ts --out myfile.js it travels through all of the modules and compiles each in the same path that the .ts file exists, without placing the final file(s) in the properly specified path. It does however create an empty file where I would like it to end up.
I'm wondering:
1) Is it possible to use the --out parameter and only compile that one file? I do not want it to traverse imports and compile every single file, but merely do syntax / error checking at compile-time (and that's only a secondary requirement, not necessary); and
2) Is there a bug in the compiler that prevents it from properly combining / creating files? Again, the final output in the --out path directive is empty, but a file is indeed created.
Any help would be appreciated.
* Update *
While I don't want to close this question as I do believe it's still an issue, I went ahead and implemented the core TypeScript compiler to achieve what I needed to do, bypassing tsc altogether. Please see https://github.com/damassi/TypeScript-Watcher for more information and usage.
When you use the --out parameter, you get a single file with the compiler walking the dependencies and working out the correct order for the final file.
For example...
tsc --out final.js app.ts
Will find any dependencies in app.ts and compile them all too. After it works out the correct order it will save all of the JavaScript in final.js. If this JavaScript file is empty, it is normally indicative of a compiler error.
It is not possible to use the --out parameter to generate a JavaScript file for just the TypeScript file you specify, unless that file has no dependencies.