My project is developed with Symfony 3.1.0 with PHP 7.0 and I use many bundles
Since few days I have many deprecations and sometimes the toolbar return JS error ERR_CONNECTION_RESET
Can you help me on the methodology to resolve deprecations ?
How to understand logs ? Should I correct my code ? Update some bundles ? Witch ones ?
Thanks !
My composer file :
{
"name": "xxx",
"license": "proprietary",
"description": "xxx",
"type": "project",
"autoload": {
"psr-4": {
"": "src/"
},
"classmap": [
"app/AppKernel.php",
"app/AppCache.php"
]
},
"autoload-dev": {
"psr-4": {
"Tests\\": "tests/"
}
},
"require": {
"php": ">=5.5.9",
"symfony/symfony": "3.1.0",
"doctrine/orm": "^2.5",
"doctrine/doctrine-bundle": "^1.6",
"doctrine/doctrine-cache-bundle": "^1.2",
"symfony/swiftmailer-bundle": "^2.3",
"symfony/monolog-bundle": "^2.8",
"sensio/distribution-bundle": "^5.0",
"sensio/framework-extra-bundle": "^3.0.2",
"incenteev/composer-parameter-handler": "^2.0",
"doctrine/doctrine-fixtures-bundle": "~2.3",
"friendsofsymfony/user-bundle": "dev-master",
"friendsofsymfony/jsrouting-bundle": "2.0.0-alpha1",
"jms/serializer-bundle": "1.1.0",
"symfony/form": "3.1.0",
"javiereguiluz/easyadmin-bundle": "~1.14",
"cmen/google-charts-bundle": "1.*",
"blackknight467/star-rating-bundle": "^2.0",
"hwi/oauth-bundle": "0.5.x-dev",
"suncat/mobile-detect-bundle": "1.0.*",
"cspoo/swiftmailer-mailgun-bundle": "^0.3.1",
"php-http/guzzle5-adapter": "^1.0",
"symfony/finder": "^3.2",
"nategood/httpful": "^0.2.20",
"monolog/monolog": "^1.22",
"algolia/algolia-search-bundle": "^2.1",
"beberlei/DoctrineExtensions": "^1.0",
"coresphere/console-bundle": "^0.5.0",
"robertotru/to-inline-style-email-bundle": "^1.2"
},
"require-dev": {
"sensio/generator-bundle": "^3.0",
"symfony/phpunit-bridge": "^3.0",
"phpunit/phpunit": "5.4.4",
"symfony/browser-kit": "3.1.0",
"symfony/css-selector": "3.1.0"
},
"scripts": {
"post-install-cmd": [
"Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::prepareDeploymentTarget"
],
"post-update-cmd": [
"Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installAssets",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::installRequirementsFile",
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::prepareDeploymentTarget"
]
},
"extra": {
"symfony-app-dir": "app",
"symfony-bin-dir": "bin",
"symfony-var-dir": "var",
"symfony-web-dir": "web",
"symfony-tests-dir": "tests",
"symfony-assets-install": "relative",
"incenteev-parameters": {
"file": "app/config/parameters.yml"
}
}
}
My deprecations :
Referencing the "core" extension by its name (defined by getName()) is deprecated since 1.26 and will be removed in Twig 2.0. Use the Fully Qualified Extension Class Name instead. (2 times)
Referencing the "form" extension by its name (defined by getName()) is deprecated since 1.26 and will be removed in Twig 2.0. Use the Fully Qualified Extension Class Name instead. (70 times)
Calling "renderblock" on template "#WebProfiler/Collector/request.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Calling "renderblock" on template "#WebProfiler/Collector/time.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead).
Calling "renderblock" on template "#WebProfiler/Collector/memory.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Calling "renderblock" on template "#WebProfiler/Collector/ajax.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Calling "renderblock" on template "#WebProfiler/Collector/form.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Silent display of undefined block "toolbar" in template "#WebProfiler/Profiler/base.html.twig" is deprecated since version 1.29 and will throw an exception in 2.0. Use the "block('toolbar') is defined" expression to test for block existence
Calling "renderblock" on template "#WebProfiler/Collector/exception.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Calling "renderblock" on template "#WebProfiler/Collector/logger.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Silent display of undefined block "toolbar" in template "#WebProfiler/Profiler/base.html.twig" is deprecated since version 1.29 and will throw an exception in 2.0. Use the "block('toolbar') is defined" expression to test for block existence.
Calling "renderblock" on template "#WebProfiler/Collector/events.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Calling "renderblock" on template "#WebProfiler/Collector/router.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Calling "renderblock" on template "#WebProfiler/Collector/translation.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Calling "renderblock" on template "#Security/Collector/security.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Calling "renderblock" on template "#WebProfiler/Collector/twig.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Calling "renderblock" on template "#Doctrine/Collector/db.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Calling "renderblock" on template "#Swiftmailer/Collector/swiftmailer.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Calling "renderblock" on template "#Debug/Profiler/dump.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Calling "renderblock" on template "#EasyAdmin/data_collector/easyadmin.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Calling "renderblock" on template "MobileDetectBundle:Collector:device.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Calling "renderblock" on template "CoreSphereConsoleBundle:Toolbar:toolbar.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
Calling "renderblock" on template "#WebProfiler/Collector/config.html.twig" from template "#WebProfiler/Profiler/toolbar.html.twig" is deprecated since version 1.28 and won't be supported anymore in 2.0. Use block("toolbar", template) instead)
... etc...
For these notices :
Silent display of undefined block "toolbar" in template "#WebProfiler/Profiler/base.html.twig" is deprecated since version 1.29 and will throw an exception in 2.0. Use the "block('toolbar') is defined" expression to test for block existence
You must correct your base.html.twig file :
{% include('Bundle::file.html.twig') with {stylesheets: block('stylesheets')} %}
Like :
{% set sheets = null %}
{% if block('stylesheets') is defined %}
{% set sheets = block('stylesheets') %}
{% endif %}
{% include('Bundle::file.html.twig') with {stylesheets: sheets} %}
Related
I've added kotlin("kapt") to the plugins block in the build.gradle.kts file for my library module.
plugins {
id("java-library")
id ("kotlin")
kotlin("kapt")
}
Now gradle sync results in the error:
only id(String) method calls allowed in plugins {} script block
how can I make use of kapt in my library module?
For Gradle Kotlin DSL use:
plugins {
kotlin("kapt") version "version" // e.g. "1.7.21"
}
As for Groovy:
plugins {
id "org.jetbrains.kotlin.kapt" version "version" // e.g. "1.7.21"
}
I used it and it worked!
Silly me. A copy-paste mix-up caused the .kts extension to be removed from my file. Restoring the filename extension resolves the issue.
For the example, everything seems to be working with chrome debugger extension installed.
When I tried to use:
<script lang="ts">
the source map seems just mess up. Following the instructions here, I can debug in Chrome, but not in vscode anymore.
I used the version 3 vue-cli template with TypeScript in Vue.js Single-File-Components rather than the guide you have linked, but I had a similar problem.
The vue-cli v.3 template ends up outputting TypeScript components' sourcemaps into a '.' folder (but all under webpack://) while the JavaScript components' sourcemaps end up in a 'src' folder. This resulted in the default sourceMapPaths working for the JavaScript SFCs but not the TypeScript SFCs. Therefore, I could set breakpoints in Chrome debugger directly, but not in the original files in VSCode for TypeScript SFCs.
My solution was to correct the mapping via the sourceMapPathOverrides configuration (alternatively, it could be corrected by modifying the build process but this seemed like the simple approach).
In .vscode/launch.json, you can set the appropriate mappings. The config I used ended up looking similar to the following (but you may have to adjust based on your exact setup):
{
"type": "chrome",
"request": "launch",
"name": "ChromeDebug",
"url": "http://localhost:8080",
"webRoot": "${workspaceFolder}",
"breakOnLoad": true,
"sourceMaps": true,
"disableNetworkCache": true,
"sourceMapPathOverrides": {
"webpack:///*": "${webRoot}/*",
"webpack:///./*": "${webRoot}/*",
"webpack:///src/*": "${webRoot}/src/*"
}
}
(The last sourceMapPathOverrides entry is probably redundant. Your link seems to be using a '.://' root output path rather than my 'webpack://' root and you may also need to adjust the webRoot path to wherever your source files are. Don't forget to change the url/port as well, if it differs from my example.)
...
And the following is probably not related to OP's issue, but may be helpful for someone with a similar problem:
When using TypeScript, ensure that you have "sourceMap": true in your tsconfig.json.
If using vue-cli v.3, you may also need to add a vue.config.js file in the project root, such as the following, to change the devtool value from the default:
module.exports = { configureWebpack: { devtool: "source-map" } };
I am trying to suppress/fix a deprecated warning from my grunt-sass (based on node-sass) compile that I traced to Susy 2 using functions listed to deprecate in Sass 4.0. At this point, it's not feasible to upgrade to Susy 3 as there's no upgrade guide and will break a large website.
Node-sass offers a --quiet option that I've passed in my Gruntfile.js though I am still getting the warning. This is my SASS section in my Gruntfile.js.
sass: {
options: {
quiet: true,
sourceMap: false,
outputStyle: 'compressed'
},
dist: {
options: {
quiet: true
},
files: {
'static/css/style.min.css' : 'static/css/sass/style.scss',
'static/css/orderform.css' : 'static/css/sass/orderform.scss'
}
}
}
Is there a way to suppress deprecated warnings? Just ignoring the warnings will slow down my development, outputting all the warnings increases my compile time from ~1s to ~4s.
Here is the log output
Version 2.2.14 was specifically released to solve this problem. I tried to reproduce this locally in 2.2.14, but I'm not able to. I do get the warning when I write an improper call() - but I'm not able to get the same warning from Susy. Are you sure the version of Susy being used is the version in npm?
I have the following dependencies in my dotnet core application:
"dependencies": {
"xunit": "2.2.0-beta2-build3300",
"dotnet-test-xunit": "2.2.0-preview2-build1029",
"Moq": "4.0.10827"
},
And no matter what version i download of Moq its simply just not supported, it says:
Package Moq 4.0.10827 is not compatible with netcoreapp1.0 (.NETCoreApp,Version=v1.0). Package Moq 4.0.10827 supports:
- net35 (.NETFramework,Version=v3.5)
- net40 (.NETFramework,Version=v4.0)
- sl4 (Silverlight,Version=v4.0)
One or more packages are incompatible with .NETCoreApp,Version=v1.0.
But i read on this blogpost: Moq on .NET Core that it was possible, i have the nuget plugin in studio code, so it autocompletes packages, i just cannot find any package when i write moq.netcore Maybe i am asking more of an approach to finding out if such a plugin actually exists, more than an answer, because right now i can't see on nuget if packages are supported in dotnet Core, how do you guys check if it has support? and do you only look for packages on Nuget.org ?
Thanks
EDIT: Solution project.json:
{
"version": "1.0.0-*",
"testRunner": "xunit",
"dependencies": {
"xunit": "2.2.0-beta2-build3300",
"dotnet-test-xunit": "2.2.0-preview2-build1029",
"moq": "4.6.38-alpha"
},
"frameworks": {
"netcoreapp1.0": {
"dependencies": {
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.0"
}
}
}
}
}
I guess current stable version in Nuget is 4.5.23 and in your code you have mentioned it should be 4.0.10827, may be that is causing problem.
As shown in your error, Moq 4.0.10827 is not compatible with netcoreapp1.0 and it only supports till 4.0, Look here for more details on versions of Moq
I have also wrote blog on Moq in .Net core, which is here. But I make changes in this everyday due to new changes.
Edit: As per DenLilleMand:
4.6.38-alpha works - but e.g. 4.5.3 doesn't work, that complains that Moq 4.5.3 supports net45 and one or more packages are incompatible
with .NETCoreApp V1.0.
Allright, he is the thing. I am using curl.js for my AMD loader, but i don't like much of "cram" because it needs to be run on unix and i am developing on Windows. So the r.js adapter for nodeJS from RequireJS library comes in mind, because node has already binary for Windows.
Now jQuery in current version (1.6.4) is not valid AMD module (coming in version 1.7) and there is dependencies in jQueryUI components, so i had to fake like this:
curl( [js!Core/jquery.js] )
.then( function() {
define('jquery', function() { return jQuery; });
})
My application is happy with this. However using r.js (version 0.26.0) fails on this part with following error:
Tracing dependencies for: boot
function (){return jQuery}
node.js:207
throw e; // process.nextTick error, or 'error' event on first tick
^
ReferenceError: jQuery is not defined
at eval at <anonymous> (r.js:7468:30)
at main (r.js:770:33)
at callDefMain (r.js:840:18)
This is my app.build.js
({
appDir: '../',
baseUrl: 'Scripts/',
paths: {
'link': '../../../Lib/#Javascript Libs/curl.js/src/curl/plugin/link.js'
},
dir: 'built',
optimize: 'none',
modules: [
{ name: 'boot' }
]
})
And here is complete boot.js for reference (coffeescript):
require([
'link!styles/main.css'
'js!Core/jquery.js!order'
'js!Core/underscore.js!order'
'js!Core/backbone.js!order'
]).then ->
define 'jquery', -> jQuery
.next(['Router/MainRouter'])
.then (MainRouter) ->
new MainRouter()
Backbone.history.navigate('home') unless Backbone.history.start(
pushState: false
)
Thank you in advance for any hint where the catch can be...
Correct. RequireJS uses a different syntax on its global requirejs() (aka require()) function. RequireJs also doesn't have the "js!" plugin built-in. You may have to include a path to it in your config. You could also use RequireJS's syntax for non-module javascript files.
Also: cram 0.2 will support Windows environments using Rhino. We're writing tests for cram 0.2 and will be releasing it shortly.
RequireJS syntax (remove js! prefix and include .js extension):
require([
'link!styles/main.css'
'order!Core/jquery.js'
'order!Core/underscore.js'
'order!Core/backbone.js'
], function (maincss, jQuery, underscore, backbone) {
// do something here
});