Hello this questions is having a minimal working example of what Im trying to build.
Im having troubles to run flow-type checker on just simple JS file. Here is how the file looks like
// #flow
import type { Map } from 'immutable';
And I even build a minimal working (NOT working) example with travis running it.
Here is the repository. It's very simple and only has flow and immutable-js dependencies.
https://github.com/RusAlex/immutable-flow
and here is the failed Travis-ci build
https://travis-ci.org/RusAlex/immutable-flow/builds/243260858
Flow reads the package.json to find out about imports, but since you moved your .flowconfig inside your src/ folder, it no longer can. If you include the package.json by adding ../package.json to your [include] you get an interesting error:
src/flow.js:2
2: import { Map } from 'immutable';
^^^^^^^^^^^ This modules resolves to "<<PROJECT_ROOT>>/../node_modules/immutable/package.json", which is outside both your root directory and all of the entries in the [include] section of your .flowconfig. You should either add this directory to the [include] section of your .flowconfig, move your .flowconfig file higher in the project directory tree, or move this package under your Flow root directory.
Finally, adding ../node_modules/immutable/ will help flow resolve everything again.
Alternatively, you could just add .flowconfig to the actual project root. It makes things simpler and seems to be the intended default.
Related
I have a react application created using "create react app rewired". I've installed ts-jest and want to be able to customize Jest. I read the documentation from ts-jest and executed npx ts-jest config:init at the root level of my project to create the initial configuration file. To test that jest is indeed using that configuration file, I wrote the following line console.log(window); in a sample test file and modified the configuration such that testEnvironment is set to "node".
I am expecting the test to fail due to window being undefined, but I am getting the window object back. I tried renaming the file to jest.config.ts and I got the same result.
I did a global search across all the files to see if there's another configuration file somewhere that is overriding my configurations, but there was none found.
What am I doing wrong? I know jest comes pre-packaged with create-react-app (CRA). I would imagine that create-react-app-rewired would only include some wrapper above CRA so where is it getting its configurations from?
I've come to realize that create-react-app-rewired package had nothing to do with this issue since it is simply a wrapper package that exposes a configure-overrides.js file to allow developers to modify the webpack configurations managed by create-react-app.
The jest.config.ts or jest.config.js config file I created had no effect because create react app (CRA) will generate and use its own jest config file underneath the hood.
I discovered this by happenstance while researching on another issue. A comment by dstapleton92 on GitHub helped me draw this conclusion.
Create React App supports overriding SOME of the values via the "jest" property in package.json file. Upon inspecting the jest config factory function in CRA, testEnvironment property is hard coded to "jsdom" and the key is not exposed as part of the list of overridable properties.
This is why the attempts I made were not successful.
The new Chrome 64 security update seems to have broken the htmlToImage libraries. None of the styling is correctly calculated and is rendered as if no styling was applied at all.
Does anyone know of a workaround / fix? Do I need to put my CSS on the server and allow CORS?
I just fixed this error.
Forked the lib and made a pull request. Until it gets merged, you can use the forked repo: https://github.com/kmap-io/html-to-image
by replacing the target of html-to-image in your package.json with:
"html-to-image": "git+https://github.com/kmap-io/html-to-image.git"
About the bug
Chrome is complaining (throws an error) about trying to read a property that does not exist. Firefox also complains, but they only throw a warning, instead of an error. The fix consists of replacing
if (sheet.cssRules) {
...
with
if (sheet.hasOwnProperty('cssRules')) {
...
There is no downside (i.e.: when cssRules exists on sheet - which is a stylesheet - the script iterates through the rules and adds them to document, as supposed to).
How to patch (until it gets merged).
For some reason, simply replacing the library's repo with the fork in which I committed the change doesn't work for this package. I asked the lib's author to add instructions on how to build after a pull-request, as they state in the readme pull requests and contributions are welcome. Until then, here's how to apply the fix using patch-package:
add "prepare": "patch-package" inside scripts, in your project's package.json
npm i patch-package --save-dev
In node_modules/html-to-image/lib/embedWebFonts.js, change line 7 from
try {
to
if (sheet.hasOwnProperty('cssRules')) try {
npx patch-package html-to-image
If you have a deployment script that builds your project from scratch, you'll need to apply the patches right before you call npm run build (or similar, depending on your stack):
git apply --ignore-whitespace patches/*.patch
That's about it.
When the fix will be merged, you'll need to run:
npx patch-package html-to-image --reverse
I fiddled around with it for more than 8 hours without getting it resolved.
All I want is to call a ViewHelper in a Fluid template. I did that before and I never had a similar problem.
My ViewHelper file is located in
EXTDIR/VendorName/Classes/ViewHelpers/SomeViewHelper.php.
In my Fluid Template I use the namespace
{namespace k=VendorName\Extname\ViewHelpers}.
Somewhere in the template I call the ViewHelper with
{k:some()}.
The ViewHelper script "SomeViewHelper.php" contains the following code:
class SomeViewHelper extends Tx_Fluid_Core_ViewHelper_AbstractViewHelper {
public function initializeArguments() { }
public function render() {
return 7;
}
}
As you can see, the whole thing is quite simple and the expected output on the page should be "7". But calling a page in the frontend produces this error message:
Oops, an error occurred!
Could not analyse class:VendorName\Extname\ViewHelpers\SomeViewHelper maybe not loaded
or no autoloader?"
Any hints on what might be wrong here?
Cheers
Michael
If everything is spelled correct, and even after deleting System/Configuration Cache the ViewHelper doesn't come up (Could not analyse.. / maybe not loaded or no autoloader), try to reinstall the extension in extension manager!
Your path to the viewHelper source file is wrong.
The correct path should be (without vendorname):
EXTDIR/Classes/ViewHelpers/SomeViewHelper.php
You also need to make sure, you use the correct namespace for your viewHelper (if you're on TYPO3 6+, don't use the old Tx_ classes but namespaces).
<?php
namespace VendorName\Extname\ViewHelpers;
class SomeViewHelper extends \TYPO3\CMS\Fluid\Core\ViewHelper\AbstractViewHelper {
public function initializeArguments() { }
public function render() {
return 7;
}
}
The error message seems to indicate that the class is not found.
Without more info, I would probably suspect a typo somewhere (pun not intended).
The following assumes you are using TYPO3 7 and not composer mode:
First, please check if your viewhelper class is autoloaded. This will help to narrow down the problem. On the command line in the htdocs directory: grep SomeViewHelper typo3temp/autoload/autoload_classmap.php This should give you a hit, if the ViewHelper class is included in the autoload file.
If the classes are not autoloaded, you might manually want to do the autoloading: On the command line in the htdocs directory: php typo3/cli_dispatch.phpsh extbase extension:dumpclassloadinginformation
For more information see: https://docs.typo3.org/typo3cms/CoreApiReference/ApiOverview/Autoloading/Index.html. For more in depth info see this: http://insight.helhum.io/post/130876393595/how-to-configure-class-loading-for-extensions-in You can find this functionality of autoloading in the install tool in TYPO3 8, so in that case you would not need to run the command on the command line.
If this does not work either, check the following:
Are you using namespace correctly in the class: <?php namespace VendorName\Extname\ViewHelpers\SomeViewHelper;
Is the path (including Camelcase class name) correct: /Classes/ViewHelpers/SomeViewHelper.php
After that, clear the system cache and reinitiate the autoloading as described above.
In order for the autoloading to be initiated automatically, you might have to update your ext_emconf.php (if you are not using composer mode) or composer.json (if you are using composer mode).
Just some questions:
Did you add the TypoScript Template of the Extension to the Static Includes?
If you're using a unix-alike system, are you sure that your webserver has the permission to read that files?
If TYPO3 is installed in composer mode and your extension is not installed via composer (e.g. a ProviderExtension of FluidTYPO3), you must provide autoload information for your extension in the main composer.json file, as described within TYPO3-composer-documentation:
In Composer Mode all class loading information must be provided by each of the installed extensions or the root package. If TYPO3 extensions are not installed by composer, e.g. because they are directly committed to the root package or a new package is kickstarted, class loading information needs to be provided, otherwise no classes can be loaded for these extensions/ packages.
E.g. if you have a site extension directly committed to your root package, you must include the class loading information in the root package like that:
Drove me crazy to get my ViewHelpers autoloaded. Providing the autoload-information within a composer.json or the ext_emconf.php of the extension and reinstalling it didn't do the trick.
I've got a project where src/main/webapp/com/mycompany/frontend/page/index.js depends on target/webjars/log4javascript/1.4.10/log4javascript.js.
I've added package.json alongside index.js with the following contents:
{
"browser":
{
"log4javascript": "../../../../../../../target/webjars/log4javascript/1.4.10/log4javascript.js"
}
}
I've got many other dependencies in the target directory. Is there a way for me to avoid repeating ../../../../../../../target/ for every dependency?
One option is to put the directory that contains your local modules, or a symlink to it, in node_modules, such as node_modules/app and then reference your requires as app/..., e.g. I believe this would work
{
"browser":
{
"log4javascript": "app/target/webjars/log4javascript/1.4.10/log4javascript.js"
}
}
Or you could structure it however you want, e.g. node_modules/log4javascript (which, if you have symlinks, could point to /whatever/target/webjars/log4javascript).
This makes it so that require() will find it in the same fashion as npm modules, without publishing it to npm. The main drawback to this is that it breaks the ability to programatically configure transforms, e.g. with browserify('app/entry').transform(whatever), app/entry and other files in the dependency graph that are under node_modules will not have the transform applied to them.
Check out the section Using Non-Relative Paths in this article.
You can use grunt-browserify's aliasMapping option to specify the root of your app:
aliasMappings: [{
cwd: 'src',
dest: 'myApp',
src: ['**/*.js']
}]
and then you can directly refer to everything from the root path, without having to ever use any dreaded ../'s:
require("myApp/target/webjars/log4javascript/1.4.10/log4javascript.js")
Of course, this doesn't resolve the problem that it's still a very long path.
The article's next paragraph makes a very good point: if you're calling things way over at the other end of your application like that, it's a good sign that things may not be correctly architected.
Can you split the functionality into smaller modules? Perhaps make log4javascript its own module?
Add to my answer, from discussion below:
If log4javascript is in your package.json file as a browser (non-NPM) module, you should just be able to require it with require('log4javascript')
I have a module. Inside it, I'd like to access data from my parent application's package.json file. What's the best practice way to do that?
I've done this the janky way by going up 2 levels and requiring the file (or using the nconf configuration loader).
var appdir = path.resolve(__dirname, '../../');
nconf.file('app', path.join(appdir, 'package.json'));
But that seems like it could break easily.
Also I heard about pkginfo, it will automatically grab info from my own module's package.json, but I'm looking to get data from the parent application's.
Thanks for any help!
EDIT: I suppose another way of asking is, how can I get the application's path (instead of the module path) ?
You can use
require.main.require './package'
But it'll work only if your parent application's file is in a root of it's directory.
You can also wrap it into try ... catch and add ../ to path till you find package.json.
You can read more about accessing main module here http://nodejs.org/api/modules.html#modules_accessing_the_main_module
Adding to pcru's approach, this should work:
function loadMainPackageJSON(attempts) {
attempts = attempts || 1;
if (attempts > 5) {
throw new Error('Can\'t resolve main package.json file');
}
var mainPath = attempts === 1 ? './' : Array(attempts).join("../");
try {
return require.main.require(mainPath + 'package.json');
} catch (e) {
return loadMainPackageJSON(attempts + 1);
}
}
var packageJSON = loadMainPackageJSON();
Keep in mind that this will get you the main module, which something you think is what you want , but if you're building a command line tool like I was, what you really want is to get the package.json exactly two folders above where you were installed if your tool is meant to be installed locally and called with npm run-script
As mentioned in Determine project root from a running node.js application , one of the easiest ways to get to your application path is using process.cwd(), provided you have the discipline to always start your main js program from the same directory. i.e. node app/main.js and cd app && node main.js will give different results.
Another way could be to recursively follow the references to module.parent, then read out module.filename when module.parent is undefined. This also presupposes some knowledge about your app. It won't work if the location of the main script relative to the package.json could vary. I.e. you must know if the main script is in the root of the app directory, or maybe in some sort of 'bin', 'app', or 'lib' dir. However, once you find the top-level module, you could try to locate the closest package.json using the same algorithm pkginfo uses to find the package.json for the current file.